kubernetes快速入门13-网络

在kubernetes中容器有四种网络模型：

bridge，桥接式网络，自由式网络名称空间
joined，共享使用另外容器的网络空间
opened，容器直接共享宿主机的网络名称空间
Closed或None，不使用任何网络空间

docker网络存在的问题：跨越节点间容器访问时要经过各自宿主机的网络并做SNAT和DNATl转换，发起方容器访问目标容器是访问目标容器所在宿主机的网络，通过DNAT转换才能访问到目标容器，目标容器看不到发起方容器的IP地址，而发起方也看不到目标容器的IP地址。通过SNAT和DNAT转换进行通信效率低。

kubernetes快速入门13-网络

k8s的网络通信：

容器间通信：同一个pod内的多个容器间的通信，直接使用lo回环地址
pod间通信：直接使用Pod的网络IP地址通信
Pod与Service通信： Pod的IP与ClusterIP进行通信
Service与集群外部的通信：外部的LB，ingress, NodePort

k8s自己不提供网络解决方案，它支持CNI(容器网络插件，这只是一种规范)网络插件方式引入网络解决方案，常见有flannel，calico，canal等，canal是flannel和calico的结合产物，在flannel的基础上增加的网络策略的实现。

flannel网络

flannel支持多种报文的承载方式：

VxLAN，使用隧道网络实现，开销较大，这是flannel的默认工作方式。

VxLAN也有两种工作方式：
1. 原生vxlan
2. directrouting, 直接路由，两个物理节点在同一个三层网络中则使用直接路由，如果物理节点之间有路由器进行隔离，那就降级为使用原生的vxlan的隧道叠加方式通信

host-gw: host gateway 主机网关，把宿主机的物理网卡虚拟出一个网卡作为pod的默认网关，通过路由表转发的方式实现跨物理节点的Pod间的访问，各个物理节点需要在同一个三层网络中
UDP，使用普通的UDP方式，效率很低，建议不要使用

flannel的配置参数

Network: flannel使用的CIDR格式的网络地址，用于为Pod配置网络功能
SubnetLen: 把Network切分子网供各节点使用时，使用多长的掩码进行切分，默认为24位
SubnetMin: 用于分配给节点子网的起始网络
SubnetMax: 用于分配给节点子网的最大网络
Backend: flannel的工作方式，vxlan, host-gw, udp

flannel工作原理探索

flannel插件被安装后默认以vxlan的方式工作，并以DaemonSet控制器管理flannel的Pod，即每个物理节点上运行一个此pod，该pod共享宿主机的网络名称空间。

在node02节点上查看当前的网络接口及路由信息

root@node02:~# ifconfig
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.1.1  netmask 255.255.255.0  broadcast 10.244.1.255
        ...
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
       ...
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.101.41  netmask 255.255.255.0  broadcast 192.168.101.255
        ...

flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.1.0  netmask 255.255.255.255  broadcast 0.0.0.0
        ...
...

cni0和flannel.1两个接口是部署完flannel后自动生成的网络接口，cni0为一个网桥设备，负责该节点上容器间的通信，当该节点中的Pod需要访问该节点外的pod时数据报文就会通过flannel.1接口进行隧道报文封装。这两个接口的mtu值为1450，为隧道报的封装预留了一些空间。

再来看看该主机的路由信息

root@node02:~# ip route
default via 192.168.101.1 dev ens33 proto static
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 # 本机的pod就直接走cni0网络
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink  # 其他节点的pod网络需要走flannel.1接口进行隧道转发
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.101.0/24 dev ens33 proto kernel scope link src 192.168.101.41

从路由信息可知如果要访问其他节点的上Pod，那就需要把数据路由到flannel.1这个接口上进行隧道报文封装，毕竟使用了隧道技术，开销较大。

以一个Ping报文的事例来看看Pod间数据是怎么进行通信的

k8s@node01:~$ kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE    IP             NODE     NOMINATED NODE   READINESS GATES
myapp-0   1/1     Running   1          20h    10.244.2.117   node03   <none>           <none>
myapp-1   1/1     Running   2          2d5h   10.244.1.88    node02   <none>           <none>
myapp-2   1/1     Running   2          2d5h   10.244.2.116   node03   <none>           <none>

# 在node03上运行的Pod中对node02上运行的Pod进行ping操作
k8s@node01:~$ kubectl exec -it myapp-0 -- /bin/sh
/ # ping 10.244.1.88

# 在node02上抓包看看
root@node02:~# tcpdump -i flannel.1 -nn icmp  # flannel.1接口能看到icmp包的信息
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes
15:03:27.659305 IP 10.244.2.117 > 10.244.1.88: ICMP echo request, id 5888, seq 69, length 64
15:03:27.659351 IP 10.244.1.88 > 10.244.2.117: ICMP echo reply, id 5888, seq 69, length 64
...
root@node02:~# tcpdump -i cni0 -nn icmp  # cni0也能看到icmp包的信息
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:03:45.672189 IP 10.244.2.117 > 10.244.1.88: ICMP echo request, id 5888, seq 87, length 64
15:03:45.672244 IP 10.244.1.88 > 10.244.2.117: ICMP echo reply, id 5888, seq 87, length 64
...

# 物理接口ens33上没有icmp包的信息，这是因为从node03节点上的Ping包在进入到node02节点时就被flannel进行了隧道封装，使用了overlay网络叠加技术，所以直接抓icmp包是看不到的，但对数据包进行分析，可以看到被封装后的报文，如下
root@node02:~# tcpdump -i ens33 -nn
...
13:54:50.800954 IP 192.168.101.42.46347 > 192.168.101.41.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.2.117 > 10.244.1.88: ICMP echo request, id 3328, seq 4, length 64
13:54:50.801064 IP 192.168.101.41.51235 > 192.168.101.42.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.1.88 > 10.244.2.117: ICMP echo reply, id 3328, seq 4, length 64
...

flannel网络优化

默认的vxlan工作方式在跨节点间的访问时进行隧道转发，效率不高，flannel还支持增加一个Directrouing参数，让其在跨节点间通信时直接使用路由技术，而不使用隧道转发，这样可以提高性能。

先下载在部署flannel网络插件时的yaml文件，并增加Directrouing参数

k8s@node01:~/install_k8s$ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

# 编辑该文件，并在ConfigMap资源中的“net-conf.json”这个key的值中增加"Directrouing"
k8s@node01:~/install_k8s$ vim kube-flannel.yml
...
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan",
        "Directrouting": true   # 增加此key/value，注意上一行尾的逗号
      }
    }
...

# 先删除之前部署的flannel
k8s@node01:~/install_k8s$ kubectl delete -f kube-flannel.yml
# 再部署flannel
k8s@node01:~/install_k8s$ kubectl apply -f kube-flannel.yml

再来看看node02节点上的路由信息

root@node02:~# ip route show
default via 192.168.101.1 dev ens33 proto static
10.244.0.0/24 via 192.168.101.40 dev ens33
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
10.244.2.0/24 via 192.168.101.42 dev ens33   # 到其他节点的Pod网络就直接走物理接口
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.101.0/24 dev ens33 proto kernel scope link src 192.168.101.41

现在到10.244.2.0/24时就不再走flannel.1接口，而是直接路由到物理接口ens33。而现在使用tcpdump命令在ens33接口上抓到相应Pod间的ICMP包。

host-gw的工作方式有点类似vxlan的directrouting，都是把宿主机的物理接口当作网关使用，只是在使用host-gw时要求集群内的所有节点都应该在同一个三层网络中。

注意： 生产环境中k8s集群已在跑业务时不能直接删除flannel后再增加参数后再应用，这样会导致集群中的Pod间通信中断。在刚部署好集群时就应该做flannel网络的优化。

基于Calico网络策略

更多关于calico的信息请参考：https://www.projectcalico.org/

Calico是针对容器，虚拟机和基于主机的本地工作负载的开源网络和网络安全解决方案。Calico支持广泛的平台，包括Kubernetes，OpenShift，Docker EE，OpenStack和裸机服务。

flannel解决了跨物理节点间pod网络的通信，但它缺少定义网络策略的功能，Calico同样能提供pod间的网络，也能提供网络策略，但Calico较flannel较为复杂，学习门槛较高，所以我们可以在使用flannel提供网络下再安装Calico，只使用它的网络策略功能。

flannel提供基础网络，而让Calico提供网络策略的安装请参考：https://docs.projectcalico.org/getting-started/kubernetes/flannel/flannel

Calico也需要依赖etcd数据库，可以自己独享使用一套，但需要单独搭建一套etcd，而k8s集群中已经有etcd服务，所以可以共享这一套etcd，但Calico也不是直接调用该etcd进行读写，而是调用k8s的api server接口进行的。

# 下载其实就是 canal 这个网络插件，项目地址：https://github.com/projectcalico/canal，其文档文档也是跳转到calico的文档
k8s@node01:~/install_k8s$ wget https://docs.projectcalico.org/manifests/canal.yaml
# 应用后会创建一大堆资源对象，大部分都是CRD(自定义资源定义)
k8s@node01:~/install_k8s$ kubectl apply -f canal.yaml
configmap/canal-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrole.rbac.authorization.k8s.io/flannel configured
clusterrolebinding.rbac.authorization.k8s.io/canal-flannel created
clusterrolebinding.rbac.authorization.k8s.io/canal-calico created
daemonset.apps/canal created
serviceaccount/canal created
deployment.apps/calico-kube-controllers created
serviceaccount/calico-kube-controllers created

Canal网络插件也是使用daemonset控制器管理，一个物理节点只运行一个pod，且共享物理节点的网络名称空间。相关资源都存放在kube-system名称空间。

k8s@node01:~/install_k8s$ kubectl get pods -n kube-system -o wide
NAME                                       READY   STATUS    RESTARTS   AGE     IP               NODE     NOMINATED NODE   READINESS GATES
calico-kube-controllers-578894d4cd-t66mz   1/1     Running   0          2m3s    10.244.2.126     node03   <none>           <none>
canal-fcpmq                                2/2     Running   0          2m3s    192.168.101.41   node02   <none>           <none>
canal-jknl6                                2/2     Running   0          2m3s    192.168.101.42   node03   <none>           <none>
canal-xsg99                                2/2     Running   0          2m3s    192.168.101.40   node01   <none>           <none>
...

安装完成后，k8s中会多出一个名叫networkpolicy的资源对象，可简写为netpol，同样可以使用kubectl explain networkpolicy查看资源的帮助信息

KIND:     NetworkPolicy
VERSION:  networking.k8s.io/v1

FIELDS:
spec    <Object>
    egress  <[]Object>  定义出站策略
        ports   <[]Object>  出站规则中定义对方开放的端口列表
            port    <string>  若不指定，则表示所有端口
            protocol    <string> TCP, UDP, or SCTP. defaults to TCP
        to  <[]Object>  出站到对方的对象，可以是以下几类对象
            ipBlock <Object>  ip块，描述一个网段，一个ip地址
                cidr    <string> -required-  cidr格式的地址
                except  <[]string>   排除地址，也是cidr格式的地址
            namespaceSelector   <Object>  名称空间标签选择器，出站到指定的名称空间
                matchLabels <map[string]string>
                matchExpressions    <[]Object>
            podSelector <Object>  pod标签选择器，出站到指定的一类pod
                matchLabels <map[string]string>
                matchExpressions    <[]Object>
    ingress <[]Object>  定义入站策略
        from    <[]Object>  入站是从何而来，同样类似"egress.to"
            ipBlock <Object>
            namespaceSelector   <Object>
            podSelector <Object>
        ports   <[]Object>  需要访问的端口列表，与"egress.ports"类似
            port    <string>
            protocol    <string>
    podSelector <Object> -required-  策略应用在哪些Pod上，同样使用标签选择器，如果设置为空，即{}，即表示该名称空间的所有pod
        matchLabels <map[string]string>
        matchExpressions    <[]Object>
    policyTypes <[]string>  策略类型，"Ingress", "Egress", or "Ingress,Egress"，显示声明策略类型，会影响入站或出站的默认行为。1. 如果值为“Ingress”，仅ingress入站策略生效，egress出站策略无效；2. 若未定义ingress规则，则ingress默认规则为拒绝所有；3. 若定义了ingress规则，则按照该规则动作；4. 若ingress规则为空，即"{}",则放行所有的入站流量；“Egress”类似，可以多测试看看

先创建两个名称空间便于做测试

k8s@node01:~/install_k8s$ kubectl create namespace dev
k8s@node01:~/install_k8s$ kubectl create namespace prod

再在两个名称间中运行受Deployment控制器控制的pod

k8s@node01:~/networkpolicy$ cat deployment-pods.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-pod
        image: ikubernetes/myapp:v1
k8s@node01:~/networkpolicy$ kubectl apply -f deployment-pods.yaml -n dev
deployment.apps/myapp-deploy created

k8s@node01:~/networkpolicy$ kubectl get pods -n dev -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
myapp-deploy-6f96ddbbf9-x4jps   1/1     Running   0          96s   10.244.2.3   node03   <none>           <none>
myapp-deploy-6f96ddbbf9-xs227   1/1     Running   0          96s   10.244.1.3   node02   <none>           <none>
k8s@node01:~/networkpolicy$ kubectl get pods -n prod -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
myapp-deploy-6f96ddbbf9-92s5g   1/1     Running   0          88s   10.244.1.4   node02   <none>           <none>
myapp-deploy-6f96ddbbf9-djwc6   1/1     Running   0          88s   10.244.2.4   node03   <none>           <none>

在没有网络策略前提下，这4个Pod间是可以互相通信的。现在利用networkpolicy制定网络策略

k8s@node01:~/networkpolicy$ cat netpol-test.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpo-test
spec:
  podSelector: {} # 应用名称空间的所有pod
  policyTypes:
  - Ingress
k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

此规则未定义ingress和egress，但策略类型指定为Ingress，表示在dev名称空间中的所有pod的入站请求使用默认的拒绝策略，在prod名称空间中的Pod中ping名称空间为dev中的pod，看是否能Ping通

k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- ping 10.244.2.3
PING 10.244.2.3 (10.244.2.3): 56 data bytes
^C
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- ping 10.244.1.3
PING 10.244.1.3 (10.244.1.3): 56 data bytes
^C
# 都无法Ping通

再试一下dev名称空间中的Pod间是否能Ping能

k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-xs227 -n dev -- ping 10.244.2.3
PING 10.244.2.3 (10.244.2.3): 56 data bytes

# 依然是不通的

这样的策略把pod的所有入站数据全部拒绝了。修改策略，开放dev名称空间中所有pod的入站点流量

k8s@node01:~/networkpolicy$ cat netpol-test.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpo-test
spec:
  podSelector: {} # 应用名称空间的所有pod
  ingress:  # 增加入站策略，但设置为空
  - {}
  policyTypes:
  - Ingress

k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

入站策略设置为空，而策略类型为Ingress，这表示入站变允许所有流量

# 在宿主机也可以直接访问dev空间中的两个Pod的ip地址，能正常访问其相当的服务
k8s@node01:~/networkpolicy$ curl 10.244.2.3
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
k8s@node01:~/networkpolicy$ curl 10.244.1.3
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

修改策略，允许10.244.0.0/16网段访问dev名称空间中所有pod的所有端口，但除去prod名称空间中的pod地址为10.244.1.4/32的pod

k8s@node01:~/networkpolicy$ cat netpol-test.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpo-test
spec:
  podSelector: {} # 应用名称空间的所有pod
  ingress:
  - from:
    - ipBlock:
        cidr: 10.244.0.0/16
        except:
        - 10.244.1.4/32
  policyTypes:
  - Ingress
k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

分别在prod名称空间中的2个Pod中进行测试

# 地址为 10.244.1.4/32 的pod无法访问
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- /usr/bin/wget -O - -q 10.244.2.3
^C
# 另一个Pod则可以正常访问
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-djwc6 -n prod -- /usr/bin/wget -O - -q 10.244.2.3
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

现在想实现在dev名称空间的pod可以相互访问，但是prod名称空间的Pod则无法访dev名称空间中的pod。这里就需要使用到标签选择器，先对dev名称空间里的Pod打标签

k8s@node01:~/networkpolicy$ kubectl get pods -n dev
NAME                            READY   STATUS    RESTARTS   AGE
myapp-deploy-6f96ddbbf9-x4jps   1/1     Running   0          45m
myapp-deploy-6f96ddbbf9-xs227   1/1     Running   0          45m
k8s@node01:~/networkpolicy$ kubectl label pod myapp-deploy-6f96ddbbf9-x4jps ns=dev -n dev
pod/myapp-deploy-6f96ddbbf9-x4jps labeled
k8s@node01:~/networkpolicy$ kubectl label pod myapp-deploy-6f96ddbbf9-xs227 ns=dev -n dev
pod/myapp-deploy-6f96ddbbf9-xs227 labeled
k8s@node01:~/networkpolicy$ kubectl get pods -n dev --show-labels
NAME                            READY   STATUS    RESTARTS   AGE   LABELS
myapp-deploy-6f96ddbbf9-x4jps   1/1     Running   0          46m   app=myapp,ns=dev,pod-template-hash=6f96ddbbf9
myapp-deploy-6f96ddbbf9-xs227   1/1     Running   0          46m   app=myapp,ns=dev,pod-template-hash=6f96ddbbf9

给名称空间也打个标签

k8s@node01:~/networkpolicy$ kubectl label ns prod ns=prod
namespace/prod labeled
k8s@node01:~/networkpolicy$ kubectl label ns dev ns=dev
namespace/dev labeled
k8s@node01:~/networkpolicy$ kubectl get ns --show-labels
NAME                   STATUS   AGE    LABELS
default                Active   10d    <none>
dev                    Active   89m    ns=dev
ingress-nginx          Active   5d2h   app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
kube-node-lease        Active   10d    <none>
kube-public            Active   10d    <none>
kube-system            Active   10d    <none>
kubernetes-dashboard   Active   31h    <none>
prod                   Active   88m    ns=prod

再来修改策略文件

k8s@node01:~/networkpolicy$ cat netpol-test.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpo-test
spec:
  podSelector:
    matchLabels:
      ns: dev
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          ns: dev
  policyTypes:
  - Ingress
  k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

现在的情况为prod名称空间里的两个pod都无法访问dev名称空间中pod，而dev名称空间中的pod可以相互访问

# 无法访问
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-djwc6 -n prod -- /usr/bin/wget -O - -q 10.244.2.3
^C
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- /usr/bin/wget -O - -q 10.244.2.3
^C

k8s@node01:~/networkpolicy$ kubectl get pods -n dev -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
myapp-deploy-6f96ddbbf9-x4jps   1/1     Running   0          60m   10.244.2.3   node03   <none>           <none>
myapp-deploy-6f96ddbbf9-xs227   1/1     Running   0          60m   10.244.1.3   node02   <none>           <none>
# dev名称空间中的pod可以互相访问
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-xs227 -n dev -- /usr/bin/wget -O - -q 10.244.2.3
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

现在想开放80端口上的服务给prod中的pod访问，那修改策略文件如下

k8s@node01:~/networkpolicy$ cat netpol-test.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpo-test
spec:
  podSelector:
    matchLabels:
      ns: dev
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          ns: dev
  - from:  # 增加一条开放给prod名称空间的权限
    - namespaceSelector:
        matchLabels:
          ns: prod
    ports:
    - protocol: TCP
      port: 80
  policyTypes:
  - Ingress
k8s@node01:~/networkpolicy$ kubectl apply -f netpol-test.yaml -n dev

现在prod中的pod就可以访问dev名称空间中pod提供的http服务，但仅能访问80端口上的服务

k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-djwc6 -n prod -- /usr/bin/wget -O - -q 10.244.2.3
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- /usr/bin/wget -O - -q 10.244.2.3
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

# ping服务未开放，无法ping通
k8s@node01:~/networkpolicy$ kubectl exec myapp-deploy-6f96ddbbf9-92s5g -n prod -- ping 10.244.2.3
PING 10.244.2.3 (10.244.2.3): 56 data bytes
^C

networkpolicy的思想类似iptables，也是对出站与入站的流量进行过虑。