kubernetes快速入门13-网络
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, 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,也是对出站与入站的流量进行过虑。
- 超长干货丨Kubernetes网络快速入门完全指南
- 超长干货丨Kubernetes网络快速入门完全指南
- IdentityServer4 中文文档 -13- (快速入门)切换到混合流并添加 API 访问
- Spread for Windows Forms快速入门(13)---数据排序
- Fiddler快速入门(还有一个功能就是不经过网络,直接模拟一个响应返回给客户端)
- Linux下的网络协议分析工具-tcpdump快速入门手册
- Tensorflow搭建简易神经网络——快速入门
- Python3网络爬虫快速入门实战解析
- 网络下载快速入门
- Linux下的网络协议分析工具-tcpdump快速入门手册
- 计算机网络快速入门--2--物理层
- 生成对抗网络(GAN, Generative Adversarial Networks)快速入门
- PyTorch快速入门教程三(神经网络)
- Spread for Windows Forms快速入门(13)---数据排序
- Kubernetes快速入门
- Spark2.x学习笔记:13、Spark SQL快速入门
- Windows下C语言网络编程快速入门
- Windows下C语言网络编程快速入门
- C#forUnity快速入门(连载13)-C#结构体
- Expression Blend实例中文教程(13) - 控件模板快速入门ControlTemplates