kubernetes快速入门13-网络
在kubernetes中容器有四种网络模型：
- bridge，桥接式网络，自由式网络名称空间
- joined，共享使用另外容器的网络空间
- opened，容器直接共享宿主机的网络名称空间
- Closed或None，不使用任何网络空间
docker网络存在的问题：跨越节点间容器访问时要经过各自宿主机的网络并做SNAT和DNATl转换，发起方容器访问目标容器是访问目标容器所在宿主机的网络，通过DNAT转换才能访问到目标容器，目标容器看不到发起方容器的IP地址，而发起方也看不到目标容器的IP地址。通过SNAT和DNAT转换进行通信效率低。
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, udpflannel工作原理探索
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 createdCanal网络插件也是使用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
^Cnetworkpolicy的思想类似iptables，也是对出站与入站的流量进行过虑。
来源：oschina
链接：https://my.oschina.net/u/4354729/blog/4594620