網絡模型與網絡策略

另一篇講述的文章地址：
NetworkPolicy網絡策略以及舉例說明 https://www.cnblogs.com/sanduzxcvbnm/p/14779916.html

Kubernetes網絡模型及CNI插件

Kubernetes設計了一種網絡模型，它要求所有容器都能夠通過一個扁平的網絡平面直接進行通信（在同一IP網絡中），無論它們是否運行於集群中的同一節點。不過，在Kubernetes集群中，IP地址分配是以Pod對象為單位，而非容器，同一Pod內的所有容器共享同一網絡名稱空間。

Docker容器的網絡模型

Docker容器網絡的原始模型主要有三種：Bridge（橋接）、Host（主機）及Container（容器）。

• Bridge模型借助於虛擬網橋設備為容器建立網絡連接
• Host模型則設定容器直接共享使用節點主機的網絡名稱空間
• Container模型則是指多個容器共享同一個網絡名稱空間，從而彼此之間能夠以本地通信的方式建立連接

Docker守護進程首次啟動時，它會在當前節點上創建一個名為docker0的虛擬網橋設備，並默認配置其使用172.17.0.0/16網絡，該網絡是Bridge模型的一種實現，也是創建Docker容器時默認使用的網絡模型。

創建Docker容器時，默認有四種網絡可供選擇使用，從而表現出了四種不同類型的容器

然而，在生產環境中使用容器技術時，跨節點的容器間通信反倒更為常見，可根據網絡類型將其實現方式簡單划分為如下幾種。

• 為各Docker節點創建物理網絡橋接接口，設定各節點上的容器使用此橋設備從而直接暴露於物理網絡中。
• 配置各節點上的容器直接共享使用其節點的網絡名稱空間。
• 將容器接入指定的橋設備，如docker0，並設置其借助NAT機制進行通信。

第三種方案是較為流行且默認的解決方案。不過，此種方案的IPAM（IP Address Management）是基於容器主機本地范圍進行的，每個節點上的容器都將從同一個網絡172.17.0.0/16中獲取IP地址，這就意味着不同Docker主機上的容器可能會使用相同的地址，因此它們也就無法直接通信。

解決此問題的通行方式是為NAT。所有接入到此橋設備上的容器均會被NAT隱藏，它們發往Docker主機外部的所有流量都會在執行過源地址轉換后發出，並且默認是無法直接接收節點之外的其他主機發來的請求的。若要接入Docker主機外部的流量，則需要事先通過目標地址轉換甚至額外的端口轉換將其暴露於外部網絡中.

故此，傳統的解決方案中，多節點上的Docker容器間通信依賴於NAT機制轉發實現。這種解決方案在網絡規模龐大時將變得極為復雜、對系統資源的消耗較大且轉發效率低下。此外，docker host的端口也是一種稀缺資源，靜態分配和映射極易導致沖突，而動態分配又很容易導致模型的進一步復雜化。

Kubernetes網絡模型

Kubernetes的網絡模型主要可用於解決四類通信需求：同一Pod內容器間的通信（Container to Container）、Pod間的通信（Pod to Pod）、Service到Pod間的通信（Service to Pod）以及集群外部與Service之間的通信（external to Service）。

（1）容器間通信
Pod對象內的各容器共享同一網絡名稱空間，它通常由構建Pod對象的基礎架構容器所提供，所有運行於同一個Pod內的容器彼此之間可通過lo接⼜完成交互.

（2）Pod間通信
各Pod對象需要運行於同一個平面網絡中，每個Pod對象擁有一個集群全局唯一的地址並可直接用於與其他Pod進行通信，此網絡也稱為Pod網絡。
另外，運行Pod的各節點也會通過橋接設備等持有此平面網絡中的一個IP地址，這就意味着Node到Pod間的通信也可在此網絡上直接進行。因此，Pod間的通信或Pod到Node間的通信比較類似於同一IP網絡中主機間進行的通信。

（3）Service與Pod間的通信
Service資源的專用網絡也稱為集群網絡（Cluster Network），需要在啟動kube-apiserver時經由“--service-cluster-ip-range”選項進行指定，而每個Service對象在此網絡中均擁一個稱為Cluster-IP的固定地址。管理員或用戶對Service對象的創建或更改操作由API Server存儲完成后觸發各節點上的kube-proxy，並根據代理模式的不同將其定義為相應節點上的iptables規則或ipvs規則，借此完成從Service的Cluster-IP與Pod-IP之間的報文轉發。

（4）集群外部到Pod對象之間的通信
將集群外部的流量引入到Pod對象的方式有受限於Pod所在的工作節點范圍的節點端口（nodePort）和主機網絡（hostNetwork）兩種，以及工作於集群級別的NodePort或LoadBalancer類型的Service對象。不過，即便是四層代理的模式也要經由兩級轉發才能到達目標Pod資源：請求流量首先到達外部負載均衡器，由其調度至某個工作節點之上，而后再由工作節點的netfilter（kube-proxy）組件上的規則（iptables或ipvs）調度至某個目標Pod對象。

Pod網絡的實現方式

每個Pod對象內的基礎架構容器均使用一個獨立的網絡名稱空間，並共享給同一Pod內的其他容器使用。每個名稱空間均有其專用的獨立網絡協議棧及其相關的網絡接口設備。一個網絡接口僅能屬於一個網絡名稱空間，於是，運行多個Pod必然要求使用多個網絡名稱空間，也就需要用到多個網絡接口設備。不過，一個易於實現的方案是使用軟件實現的偽網絡接口及模擬線纜將其連接至物理接口。偽網絡接口的實現方案常見的有虛擬網橋、多路復用及硬件交換三種。

• 虛擬網橋：創建一對虛擬以太網接口（veth），一個接入容器內部，另一個留置於根名稱空間內並借助於Linux內核橋接功能或OpenVSwitch（OVS）關聯至真實的物理接口。
• 多路復用：多路復用可以由一個中間網絡設備組成，它暴露了多個虛擬接口，可使用數據包轉發規則來控制每個數據包轉到的目標接口。MAC VLAN為每個虛擬接口配置一個MAC地址並基於此地址完成二層報文收發，而IP VLAN是基於IP地址的並使用單個MAC，從而使其更適合VM。
• 硬件交換：現今市面上的大多數NIC都支持單根I/O虛擬化（SR-IOV），它是創建虛擬設備的一種實現方式。每個虛擬設備自身均表現為一個獨立的PCI設備，並有着自己的VLAN及與硬件強制關聯的QoS。SR-IOV提供了接近硬件級別的性能，但在公共雲中通常是不可用的。

無論上述哪種方式應用於容器環境中，其實現過程都需要大量的操作步驟。不過，目前Kubernetes支持使用CNI插件來編排網絡，以實現Pod及集群網絡管理功能的自動化。每次Pod被初始化或刪除時，kubelet都會調用默認的CNI插件創建一個虛擬設備接口附加到相關的底層網絡，為其設置IP地址、路由信息並將其映射到Pod對象的網絡名稱空間。

配置網絡接口時，kubelet將Pod對象的名稱和名稱空間作為CNI_ARGS變量的一部分進行傳遞（如“K8S_POD_NAMESPACE=default；K8S_POD_NAME=myapp-6d9f48c5d9-n77qp；”）。它可以定義每個Pod對象或Pod網絡名稱空間的網絡配置

網絡策略

Kubernetes的網絡策略功能由其所使用的網絡插件實現，因此，僅在使用那些支持網絡策略功能的網絡插件時才能夠配置網絡策略，如Calico、Canal及kube-router等。

Calico的calico/kube-controllers即為Calico項目中用於將用戶定義的網絡策略予以實現的組件，它主要依賴於節點的iptables來實現訪問控制功能

策略控制器用於監控創建Pod時所生成的新API端點，並按需為其附加網絡策略。當發生需要配置策略的事件時，偵聽器會監視到變化，控制器隨即響應以進行接口配置和策略應用。

Pod的網絡流量包含“流入”（Ingress）和“流出”（Egress）兩種方向，每種方向的控制策略則包含“允許”和“禁止”兩種。默認情況下，Pod處於非隔離狀態，它們的流量可以自由來去。一旦有策略通過選擇器規則將策略應用於Pod，那么所有未經明確允許的流量都將被網絡策略拒絕，不過，其他未被選擇器匹配到的Pod不受影響。

Kubernetes自1.8版本起才支持Egress網絡策略，此前的版本僅支持Ingress網絡策略。

配置網絡策略

Kubernetes系統中，報文流入和流出的核心組件是Pod資源，因此它們也是網絡策略功能生效的主要目標，因此，NetworkPolicy對象也要使用標簽選擇器事先選擇出一組Pod資源作為控制對象。一般來說，NetworkPolicy是定義在一組Pod資源上的用於管控入站流量的“Ingress規則”，或者說是管理出站流量的“Egress規則”，也可以是兩者組合定義，而僅部分生效還是全部生效則需要由spec.policyTypes予以定義

默認情況下，Pod對象既可以接受來自任何來源的流量，也能夠向外部發出期望的所有流量。
而附加網絡策略機制后，Pod對象會因NetworkPolicy對象的選定而被隔離：一旦名稱空間中有任何NetworkPolicy對象匹配了某特定的Pod對象，則該Pod將拒絕Network-Policy所不允許的一切連接請求，而那些未被任何NetworkPolicy對象匹配到的其他Pod對象仍可接受所有流量。
因此，就特定的Pod集合來說，入站和出站流量默認均處於放行狀態，除非有規則能夠明確匹配到它。然而，一旦在spec.policyTypes中指定了有效的規則類型，卻在networkpolicy.spec字段中嵌套定義了沒有任何規則的Ingress或Egress字段時，則表示拒絕相關方向上的一切流量。

定義網絡策略時常用到的術語及說明具體如下：

• Pod組：由網絡策略通過Pod選擇器選定的一組Pod的集合，它們是規則生效的目標Pod；可由NetworkPolicy對象通過macthLabel或matchExpression選定。
• Ingress：入站流量，即由其他網絡端點發往特定Pod組的流量，通常由流量發出的源站點（from）和流量的目標端口所定義。
• Egress：出站流量，即由特定的Pod組發往其他網絡端點的流量，通常由流量的目標網絡端點（to）和端口（ports）來進行定義。
• 端點（to，from）：流量目標和流量源相關的組件，它可以是CIDR格式的IP地址塊（ipBlock）、網絡名稱空間選擇器（namespaceSelector）匹配的名稱空間，或Pod選擇器（podSelector）匹配的Pod組。
• 端口（ports）：TCP或UDP的端口號。

無論是Ingress還是Egress流量，與選定的某Pod組通信的另一方都可使用“網絡端點”予以描述，它通常是某名稱空間中的一個或一組Pod資源，由namespaceSelector選定名稱空間后，經由ipBlock或podSelector進行指定。

在Ingress規則中，網絡端點也稱為“源端點”，它們用from字段進行標識，而在Egress規則中，網絡端點也稱為“目標端點”，它們用to字段進行標識。不過，在未定義Ingress或Egress規則時，相關方向的流量均為“允許”，即默認為為隔離狀態。而一旦在networkpolicy.spec中明確給出了Ingress或Egress字段，則它們的from或to字段的值就成了白名單列表，而空值意味着所有端點，即不限制訪問。

管控入站流量

以提供服務為主要目的的Pod對象通常是請求流量的目標對象，但它們的服務未必應該為所有網絡端點所訪問，這就有必要對它們的訪問許可施加控制。networkpolicy.spec中嵌套的Ingress字段用於定義入站流量規則，就特定的Pod集合來說，入站流量默認處於放行狀態，除非在所有入站策略中，至少有一條規則能夠明確匹配到它。Ingress字段的值是一個對象列表，它主要由以下兩個字段組成。

Ingress字段的值是一個對象列表，它主要由以下兩個字段組成。

• from<[]Object>：可訪問當前策略匹配到的Pod對象的源地址對象列表，多個項目之間的邏輯關系為“邏輯或”的關系；若未設置此字段或其值為空，則匹配一切源地址（默認的訪問策略為不限制）；如果此字段至少有一個值，那么它將成為放行的源地址白名單，僅來源於此地址列表中的流量允許通過。
• ports<[]Object>：當前策略匹配到的Pod集合的可被訪問的端口對象列表，多個項目之間的邏輯關系為“邏輯或”的關系；若未設置此字段或其值為空，則匹配Pod集合上的所有端口（默認的訪問策略為不限制）；如果此字段至少有一個值，那么它將成為允許被訪問的Pod端口白名單列表，僅入站流量的目標端口處於此列表中方才准許通過。

NetworkPolicy資源屬於名稱空間級別，它的有效作用范圍為其所屬的名稱空間。

1.設置默認的Ingress策略(拒絕/允許所有入口流量)
用戶可以創建一個NetworkPolicy來為名稱空間設置一個“默認”的隔離策略，該策略選擇所有的Pod對象，而后允許或拒絕任何到達這些Pod的入站流量。

下面的策略示例，其通過policyTypes字段指明要生效Ingress類型的規則，但未定義任何Ingress字段，因此不能匹配到任一源端點，從而拒絕所有入站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress # 沒有設置命令空間則默認命令空間為default
spec:
  podSelector: {} # 空的 podSelector 表示選擇命名空間下的所有pod
  policyTypes: ["Ingress"] # 入口網絡策略
 # 未設置進入條件，也就是不允許任何進入

若要將默認策略設置為允許所有的入站流量，則只需要顯式定義Ingress字段，並將其值設置為空以匹配所有源端點即可,沒有為入站流量定義任何規則時，本身的默認規則即為允許訪問，因此允許所有相關的入站流量時，本身無須定義默認規則.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
  ingress:
  - {}

實踐中，通常將默認策略設置為拒絕所有的入站流量，而后顯式放行允許的源端點的入站流量。

2.放行特定的入站流量
在Ingress規則中嵌套from和ports字段即可匹配特定的入站流量，僅定義from字段時將隱含本地Pod資源組的所有端口，而僅定義ports字段時則表示隱含所有的源端點。from和ports同時定義時表示隱含“邏輯與”關系，它將匹配那些同時滿足from和ports的定義的入站流量，即那些來自from指定的源端點，訪問由當前NetworkPolicy的podSelector匹配的當前名稱空間的Pod資源組上所指定的ports的請求。

from字段的值是一個對象列表，它可嵌套使用ipBlock、namespaceSelector和podSelector字段來定義流量來源，此三個字段匹配Pod資源的方式各有不同，同時使用兩個或以上的字段，彼此之間隱含“邏輯或”關系。

• ipBlock
• namespaceSelector
• podSelector
• ports字段的值也是一個對象列表，它嵌套port和protocol來定義流量的目標端口，即由NetworkPolicy匹配到的當前名稱空間內的所有Pod資源上的端口。
• port ：端口號或在Container上定義的端口名稱，未定義時匹配所有端口。
• protocol ：傳輸層協議的名稱，TCP或UDP，默認為TCP。

示例定義了如何開放myapp pod資源給相應的源站點訪問：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-myapp-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - ipBlock:
      cidr: 10.244.0.0/16
      except:
        - 10.244.3.0/24
    - podSelector:
      matchLabels:
        app: myapp
    ports:
    - protocol: TCP
      port: 80

它將default名稱空間中擁有標簽“app=myapp”的Pod資源的80/TCP端口開放給10.244.0.0/16網絡內除10.244.3.0/24子網中的所有源端點，以及當前名稱空間中擁有標簽“app=myapp”的所有Pod資源訪問，其他未匹配到的源端點的流量則取決於其他網絡策略的定義，若沒有任何匹配策略，則默認為允許訪問。

管控出站流量

通常應該將出站流量的默認策略設置為准許通過。但如果有必要對其實施精細管理，僅放行那些有對外請求需要的Pod對象的出站流量，則也可先為名稱空間設置“禁止所有”默認策略，而后定義明確的“准許”策略。

networkpolicy.spec中嵌套的Egress字段用於定義入站流量規則，就特定的Pod集合來說，出站流量一樣默認處於放行狀態，除非在所有入站策略中至少有一條規則能夠明確匹配到它。
Egress字段的值是一個字段列表，它主要由以下兩個字段組成。

• to<[]Object> ：由當前策略匹配到的Pod資源發起的出站流量的目標地址列表，多個項目之間為“或”（OR）關系；若未定義或字段值為空則意味着應用於所有目標地址（默認為不限制）；若明確給出了主機地址列表，則只有目標地址匹配列表中的主機地址的出站流量被放行。
• ports<[]Object> ：出站流量的目標端口列表，多個端口之間為“或”（OR）關系；若未定義或字段值為空則意味着應用於所有端口（默認為不限制）；若明確給出了端口列表，則只有目標端口匹配列表中的端口的出站流量被放行。

Egress規則中，to和ports字段的值都是對象列表格式，它們可內嵌的字段分別與Ingress規則中的from和ports相同，區別僅是作用到的流量方向相反。

1.設置默認Egress策略
通過創建一個NetworkPolicy對象來為名稱空間設置一個默認的隔離策略，該策略選擇所有的Pod對象，而后允許或拒絕由這些Pod發出的所有出站流量。

通過policyTypes字段指明要生效Egress類型的規則，但未定義任何Egress字段，因此不能匹配到任何目標端點，從而拒絕所有的出站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {} # 該命名空間下的所有pod
  policyTypes: ["Egress"] # 出口網絡策略
  # 未設置出口條件，也就是不允許任何出口流量

實踐中，需要進行嚴格隔離的環境通常將默認策略設置為拒絕所有出站流量，而后顯式放行允許到達的目標端點的出站流量。

2.放行特定的出站流量
示例中定義了一個Egress規則，它對來自擁有“app=tomcat”的Pod對象的，到達標簽為“app=nginx”的Pod對象的80端口，以及到達標簽為“app=mysql”的Pod對象的3306端口的流量給予放行：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-tomcat-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: tomcat
  policyTypes: ["Egress"]
  egress:
  - to:
    - podSelector:
      matchLabels:
        app: nginx
    ports:
    - protocol: TCP
      port: 80
  - to:
    - podSelector:
      matchLabels:
        app: mysql
    ports:
    - protocol: TCP
      port: 3306

需要注意的是，此配置清單中僅定義了出站規則，將入站流量的默認規則設置為拒絕所有時，還應該為具有標簽“app=tomcat”的Pod對象放行入站流量。

隔離名稱空間

彼此隔離所有的名稱空間，但應該允許它們都能夠與kube-system名稱空間中的Pod資源進行流量交換，以實現監控和名稱解析等各種管理功能。

示例為default名稱空間定義了相關的規則，在出站和入站流量默認均為拒絕的情況下，它用於放行名稱空間內部的各Pod對象之間的通信，以及與kube-system名稱空間內各Pod間的通信：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-deny-all
  namespace: default
spec:
  policyTypes: ["Ingress","Egress"]
  podSelector: {}
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-
  namespace: default
spec:
  policyTypes: ["Ingress","Egress"]
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchExpressions:
        - key: name
          operator: In
          values: ["default","kube-system"]
  egress:
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: name
          operator: In
          values: ["default","kube-system"]

需要注意的是，有些管理員可能會把一些系統附件部署到專有的名稱空間中，例如把Prometheus監控系統部署到prom名稱空間中等，所有這類的具有管理功能的附件所在的名稱空間與每一個特定名稱空間的出入流量都應該被放行。

網絡策略應用案例

假設有名為testing的名稱空間內運行着一組nginx Pod和一組myapp Pod。要求實現如下目標。
1）myapp Pod僅允許來自nginx Pod的流量訪問其80/TCP端口，但可以向nginx Pod的所有端口發出出站流量。
2）nginx Pod允許任何源端點對其80/TCP端口的訪問，並能夠向任意端點發出出站流量。
3）myapp Pod和nginx Pod都可與kube-system名稱空間的任意Pod進行任何類型的通信，以便於可以使用由kube-dns提供的名稱解析服務等。

出站和⼊站的默認策略均為“禁⽌”。

下面是測試實現步驟。
第一步： 創建testing名稱空間，並於其內基於Deployment控制器創建用於測試用的nginx Pod和myapp Pod各一個，創建相關Pod資源時順便為其創建與Deployment控制器同名的Service資源

~]$ kubectl create namespace testing
~]$ kubectl run nginx --image=nginx:alpine --replicas=1 --namespace=testing --port 80 --expose --labels app=nginx
~]$ kubectl run myapp --image=ikubernetes/myapp:v1 --replicas=1 --namespace=testing --port 80 --expose --labels app=myapp

為了便於在網絡策略規則中引⽤kube-system名稱空間，這⾥為其添加標簽“ns=kube-system”

~]$ kubectl label namespace kube-system ns=kube-system

待相關資源創建完成后，即可通過與其相關的Service資源的名稱訪問相關的服務。

找一pod客戶端分別測試訪問nginx和myapp的服務，名稱空間的默認網絡策略為准許訪問，接下來確認其訪問請求可正常通過

第二步： 定義網絡策略清單文件（testing-netpol-denyall.yaml），將testing名稱空間的入站及出站的默認策略修改為拒絕訪問，並再一次進行訪問測試

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-traffic
  namespace: testing
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

接下來，將testing-netpol-denyall.yaml定義的默認策略deny-all-traffic予以應用，為testing名稱空間設置默認的網絡策略

$ kubectl apply -f testing-netpol-denyall.yaml

回到第一步使用的交互式客戶端，再次對nginx和myapp發起訪問測試。為了避免長時間等待，這里為curl命令添加--connect-timeout選項為其定義連接超時時長。
由下面的命令可知，此時無法再訪問到nginx和myapp的相關服務

/ # curl --connect-timeout 2 nginx.testing
curl: (28) connect() timed out!
/ # curl --connect-timeout 2 myapp.testing
curl: (28) connect() timed out!
/ #

第三步： 定義流量放行規則配置清單nginx-allow-all.yaml，放行nginx Pod之上80/TCP端口的所有流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nginx-allow-all
  namespace: testing
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - ports:
    - port: 80
  - from:
    - namespaceSelector:
      matchLabels:
        ns: kube-system
  egress:
  - to:
  policyTypes:
  - Ingress
  - Egress

將上述清單文件中定義的網絡策略應用至集群中以創建相應的網絡策略

~]$ kubectl apply -f nginx-allow-all.yaml

而后再次回到交互式測試客戶端發起訪問請求進行測試，nginx已經能夠正常訪問，這同時也意味着由kube-system名稱空間中的kube-dns進行的名稱解析服務也為可用狀態

第四步： 定義網絡策略配置清單myapp-allow.yaml，放行testing名稱空間中來自nginx Pod的發往myapp Pod的80/TCP的訪問流量，以及myapp Pod發往nginx Pod的所有流量。另外，允許myapp Pod與kube-system名稱空間的任何Pod進行交互的所有流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: myapp-allow
  namespace: testing
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
      matchLabels:
        app: nginx
    ports:
    - port: 80
  - from:
    - namespaceSelector:
      matchLabels:
        ns: kube-system
  egress:
  - to:
    - podSelector:
      matchLabels:
        app: nginx
    - to:
      - namespaceSelector:
        matchLabels:
          ns: kube-system
  policyTypes:
  - Ingress
  - Egress

創建清單中定義的網絡策略

~]$ kubectl apply -f myapp-allow.yaml
networkpolicy.networking.k8s.io "myapp-allow" configured

然后切換至此前在專用終端中創建的臨時使用的交互式Pod，對myapp Pod發起訪問請求。由下面的命令結果可知，其訪問被拒絕

# curl --connect-timeout 2 http://myapp.testing
curl: (28) connect() timed out!
/ #

myapp Pod僅允許來自nginx Pod對其80/TCP端口的訪問，於是，這里進入testing名稱空間中的是nginx Pod的交互式接口，使用wget命令對myapp Pod發起訪問請求

~]$ kubectl exec -it nginx-b477df957-jb2nf -n testing -- /bin/sh
/ # wget http://myapp.testing -O - -q
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
/ #