K8s网络概述：

前两种情况是在一个主机（Node）中通信，也就是docker里面涉及到的原理，这里不详细探讨。

情况1：一个pod的两个容器之间通信：
在这里插入图片描述
情况2：一个Node中的两个pod之间通信：
在这里插入图片描述

情况3：不同node之间的pod进行通信：
在这里插入图片描述
这种方式实现的方式有：

  1. 有的基于overlay网络实现；
  2. 有的基于vxlan实现；
  3. 有的基于openvswitch实现；
  4. 有的基于BGP实现。

说到容器就不能不提 CNI，CNI 作为容器网络的统一标准，让各个容器管理平台（k8s,mesos等)都可以通过相同的接口调用各式各样的网络插件（flannel,calico,weave 等）来为容器配置网络。容器管理系统与网络插件之间的关系图如下所示。
在这里插入图片描述
网络插件的解决方案：

  1. flannel—基于overlay 不支持网络策略；
  2. calico—基于BGP 支持网络策略；
  3. canal 支持网络策略。

各种网络解决方案的对比：
在这里插入图片描述
不管哪种解决方案，每个pod都有独立IP，可以直接通信，只是性能及配置的难易及是否支持网络策略有区别。

一、Calico网络通信原理：

实验环境：
在这里插入图片描述
其中，calico是以容器的方式存在。

步骤1： 搭建etcd集群
Calico的信息存储于etcd，首先需要搭建etcd集群。具体步骤请参考：
https://blog.csdn.net/tushanpeipei/article/details/118409836?spm=1001.2014.3001.5501

[root@vms204 ~]# etcdctl member list
193cd579a601f16a: name=etcd-204 peerURLs=http://192.168.0.204:2380 clientURLs=http://192.168.0.204:2379,http://localhost:2379 isLeader=false
591f7e324267e48a: name=etcd-205 peerURLs=http://192.168.0.205:2380 clientURLs=http://192.168.0.205:2379,http://localhost:2379 isLeader=true

步骤2： 安装docker，使用etcd来存储数据

分别设置etcd的地址，存储自己的数据，修改文件/usr/lib/systemd/system/docker.service
，在ExecStart=后加入etcd的内容即可。

[root@vms204 etcd]# vim /usr/lib/systemd/system/docker.service
--cluster-store=etcd://192.168.0.204:2379
[root@vms205 etcd]# vim /usr/lib/systemd/system/docker.service
--cluster-store=etcd://192.168.0.205:2379

在两个设备上restart docker：

systemctl restart etcd
systemctl daemon-reload ; systemctl restart docker

步骤3： 在两台设备上生成Calico的配置文件：

mkdir /etc/calico

进入目录下，创建并编辑calicoctl.cfg文件

[root@vms204 calico]# cat calicoctl.cfg
apiVersion: v1
kind: calicoApiConfig
metadata:
spec:
  datastoreType: "etcdv2"
  etcdEndpoints: "http://192.168.0.204:2379"
  
[root@vms205 calico]# cat calicoctl.cfg
apiVersion: v1
kind: calicoApiConfig
metadata:
spec:
  datastoreType: "etcdv2"
  etcdEndpoints: "http://192.168.0.205:2379"

这里加载calico使用到的相关镜像，地址为：
https://download.csdn.net/download/tushanpeipei/20156748?spm=1001.2014.3001.5501
https://download.csdn.net/download/tushanpeipei/20156723
下载后导入到2台设备中。然后在两台设备上给calicoctl添加权限：

chmod +x calicoctl
mv calicoctl /bin/

在两台设备上加载镜像

[root@vms204 ~]# docker load -i calico-node-v2.tar
df64d3292fd6: Loading layer [==================================================>]  4.672MB/4.672MB
d6f0e85be2d0: Loading layer [==================================================>]  8.676MB/8.676MB
c9818c503193: Loading layer [==================================================>]  250.9kB/250.9kB
1f748fca5871: Loading layer [==================================================>]  4.666MB/4.666MB
714c5990d9e8: Loading layer [==================================================>]  263.9MB/263.9MB
Loaded image: quay.io/calico/node:v2.6.12
[root@vms205 ~]# docker load -i calico-node-v2.tar
df64d3292fd6: Loading layer [==================================================>]  4.672MB/4.672MB
d6f0e85be2d0: Loading layer [==================================================>]  8.676MB/8.676MB
c9818c503193: Loading layer [==================================================>]  250.9kB/250.9kB
1f748fca5871: Loading layer [==================================================>]  4.666MB/4.666MB
714c5990d9e8: Loading layer [==================================================>]  263.9MB/263.9MB
Loaded image: quay.io/calico/node:v2.6.12

步骤4： 建立Calico pod：

calicoctl node run --node-image=quay.io/calico/node:v2.6.12 -c /etc/calico/calicoctl.cfg

查看容器建立情况：

[root@vms204 calico]# docker ps
CONTAINER ID   IMAGE                         COMMAND         CREATED          STATUS          PORTS     NAMES
9c73a77f26eb   quay.io/calico/node:v2.6.12   "start_runit"   49 seconds ago   Up 48 seconds             calico-node
[root@vms205 calico]# docker ps -a
CONTAINER ID   IMAGE                         COMMAND         CREATED              STATUS              PORTS     NAMES
ea8f82ab22bb   quay.io/calico/node:v2.6.12   "start_runit"   About a minute ago   Up About a minute             calico-node

查看对方主机的信息：

[root@vms204 calico]# calicoctl node status
Calico process is running.

IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS  |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+---------------+-------------------+-------+----------+-------------+
| 192.168.0.205 | node-to-node mesh | up    | 08:03:17 | Established |
+---------------+-------------------+-------+----------+-------------+

IPv6 BGP status
No IPv6 peers found.

步骤5： 在任意主机上创建网络（可以同步给远端）

docker network create --driver calico --ipam-driver calico-ipam calnet1

–driver calico 指定使用 calico 的 libnetwork CNM driver。
–ipam-driver calico-ipam 指定使用 calico 的 IPAM driver 管理 IP。
calico 为 global 网络，etcd 会将 calnet1 同步到所有主机。

查看网络建立情况：可以看到创建了一个名为calnet1的网络。

[root@vms204 calico]# docker network list
NETWORK ID     NAME      DRIVER    SCOPE
c21c6b680d2e   bridge    bridge    local
a820a4b2f07d   calnet1   calico    global
bffc445a376b   host      host      local
4f378dcf68c2   none      null      local

步骤6： 在两个设备上创建容器，使用calnet1网络，检查是否能够通信

[root@204 calico]# docker run --name c204 --net calnet1 -itd busybox
[root@205 calico]# docker run --name c205 --net calnet1 -itd busybox

进入容器，查看其网卡信息：

[root@vms204 calico]# docker exec -it c204 sh
/ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: cali0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.173.0/32 scope global cali0
       valid_lft forever preferred_lft forever

[root@vms205 calico]# docker exec -it c205 sh
/ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: cali0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.242.64/32 scope global cali0
       valid_lft forever preferred_lft forever

可以看到两个容器上有一个ali0@if5的网卡。然后查看宿主机的网卡信息：

[root@vms204 calico]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:64:4b:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.204/24 brd 192.168.0.255 scope global ens32
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe64:4b0e/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:a5:fb:5f:db brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: calibe0de8fc176@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 92:e4:82:9a:33:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::90e4:82ff:fe9a:33b6/64 scope link
       valid_lft forever preferred_lft forever

[root@vms205 calico]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:1b:ea:ca brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.205/24 brd 192.168.0.255 scope global ens32
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe1b:eaca/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:40:b1:a7:b1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: cali39e20803688@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether ae:5e:a1:f5:f9:c8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::ac5e:a1ff:fef5:f9c8/64 scope link
       valid_lft forever preferred_lft forever

可以看到，宿主机上也有一个calico生成的网卡，对比容器内和宿主机的calico网卡，我们可以发现，他们是配对的（if4配对if5，veth pair，可以理解为直连）。

检查两个pod是否能够通信：

[root@vms204 calico]# docker exec -it c204 sh
/ # ping 192.168.242.64
PING 192.168.242.64 (192.168.242.64): 56 data bytes
64 bytes from 192.168.242.64: seq=0 ttl=62 time=0.328 ms
64 bytes from 192.168.242.64: seq=1 ttl=62 time=0.241 ms
64 bytes from 192.168.242.64: seq=2 ttl=62 time=0.216 ms

步骤7： 分析流量转发流程
在vms204的容器中，pingvms205时，首先查看路由表：

/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         169.254.1.1     0.0.0.0         UG    0      0        0 cali0
169.254.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 cali0

可以看到，默认有一条默认路由，出接口为calico创建的接口。因此流量从接口出来，到达此宿主机与之配对的接口，然后再宿主机上查看路由表：

[root@vms204 calico]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 ens32
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ens32
192.168.173.0   0.0.0.0         255.255.255.255 UH    0      0        0 calibe0de8fc176
192.168.173.0   0.0.0.0         255.255.255.192 U     0      0        0 *
192.168.242.64  192.168.0.205   255.255.255.192 UG    0      0        0 ens32

可以看到其上有一条去玩对端pod 192.168.242.64地址的路由，出接口为ens32，下一跳为192.168.0.205（VMS205的ens32的地址）；由于两个节点是2层通信，不需要在外部再封装IP报头。将目的MAC设置为了VMS205的ens32的MAC地址，然后发送给VMS205。VMS205收到报文后可以看到目地址是192.168.242.64，查看路由表：

[root@vms205 calico]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 ens32
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ens32
192.168.173.0   192.168.0.204   255.255.255.192 UG    0      0        0 ens32
192.168.242.64  0.0.0.0         255.255.255.255 UH    0      0        0 cali39e20803688
192.168.242.64  0.0.0.0         255.255.255.192 U     0      0        0 *

可以看到，有一条192.168.242.64的路由，出接口为calico接口，流量因此通过宿主机的calico接口发送到了其容器c205中，完成了单向的通信，echo reply报文回程类似。

返回到K8s中：

在这里插入图片描述
按照图示部署好了K8s集群，一个Master，两个worker nodes。在master设备上，可以看到如下的pods：

[root@vms201 ~]# kubectl get pods -n kube-system -o wide
NAME                                       READY   STATUS    RESTARTS   AGE    IP              NODE             NOMINATED NODE   READINESS GATES
calico-kube-controllers-78d6f96c7b-h6p86   1/1     Running   16         4d5h   10.244.58.229   vms202.rhce.cc   <none>           <none>
calico-node-hstwf                          1/1     Running   18         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
calico-node-ldfhc                          1/1     Running   24         8d     192.168.0.203   vms203.rhce.cc   <none>           <none>
calico-node-sdvzv                          1/1     Running   24         8d     192.168.0.202   vms202.rhce.cc   <none>           <none>
coredns-545d6fc579-596hb                   1/1     Running   18         8d     10.244.20.230   vms201.rhce.cc   <none>           <none>
coredns-545d6fc579-7mb9v                   1/1     Running   18         8d     10.244.20.229   vms201.rhce.cc   <none>           <none>
etcd-vms201.rhce.cc                        1/1     Running   21         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-apiserver-vms201.rhce.cc              1/1     Running   14         4d2h   192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-controller-manager-vms201.rhce.cc     1/1     Running   20         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-proxy-28x9h                           1/1     Running   18         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
kube-proxy-7qzdd                           1/1     Running   22         8d     192.168.0.202   vms202.rhce.cc   <none>           <none>
kube-proxy-m9c2c                           1/1     Running   25         8d     192.168.0.203   vms203.rhce.cc   <none>           <none>
kube-scheduler-vms201.rhce.cc              1/1     Running   20         8d     192.168.0.201   vms201.rhce.cc   <none>           <none>
metrics-server-bcfb98c76-nqc2t             1/1     Running   14         4d5h   10.244.58.237   vms202.rhce.cc   <none>           <none>

可以看到在每个设备上，都存在一个calico pod，和前面实验中的一样。不过在K8S环境中直接使用calico.yaml来配置calico，保证了K8s中每个Node之间都能够回显通信。

网络策略：

Network Policy是kubernetes中的一种资源类型，它从属于某个namespace。其内容从逻辑上看包含两个关键部分，一是pod选择器，基于标签选择相同namespace下的pod，将其中定义的规则作用于选中的pod。另一个就是规则了，就是网络流量进出pod的规则，其采用的是白名单模式，符合规则的通过，不符合规则的拒绝。

实验概述：
在集群中创建两个pod，分别关联两个SVC，正常情况下，集群外的主机是能够直接访问两个服务的，

步骤1： 使用docker拉取测试使用的镜像

docker pull yauritux/busybox-curl

步骤2： 创建两个pod和SVC

[root@vms201 calico]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    test: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}
[root@vms201 calico]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 calico]# sed 's/pod1/pod2/' pod1.yaml | kubectl apply -f -
pod/pod2 created
[root@vms201 calico]# kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
pod1   1/1     Running   0          30s
pod2   1/1     Running   0          8s

修改nginx的主页，pod1为111，pod2为222：

[root@vms201 calico]# kubectl exec pod1 -- sh -c "echo 111 > /usr/share/nginx/html/index.html"
[root@vms201 calico]# kubectl exec pod2 -- sh -c "echo 222 > /usr/share/nginx/html/index.html"

创建SVC，绑定到pods上：

[root@vms201 ~]# kubectl expose --name=svc1 pod pod1 --port=80 --type=LoadBalancer
service/svc1 exposed
[root@vms201 ~]# kubectl expose --name=svc2 pod pod2 --port=80 --type=LoadBalancer
service/svc2 exposed

[root@vms201 ~]#  kubectl get svc
NAME   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
svc1   LoadBalancer   10.107.162.113   192.168.0.240   80:31536/TCP   43s
svc2   LoadBalancer   10.98.23.70      192.168.0.241   80:30992/TCP   29s

创建测试使用的pod：可以看到，目前测试使用的pod能够正常访问两个nginx的pods。

kubectl run testpod --image=docker.io/yauritux/busybox-curl:latest -it --rm --image-pull-policy=IfNotPresent -- sh
/home # curl svc1
111
/home # curl svc2
222

在K8s官网找到网络策略的yaml文件模板进行应用：
https://kubernetes.io/docs/concepts/services-networking/network-policies/

[root@vms201 calico]# cat networkPolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

其中的podSelector表示作用于namespace中的哪个pod，使用标签的方式进行匹配。如果不写的话，表示作用于namespace中的所有pods。

  podSelector:
    matchLabels:
      role: db

policyType有两种，分别表示匹配入方向或者出方向的流量，只有在这里激活了对应的type，后续设置的策略才会生效。

  policyTypes:
  - Ingress
  - Egress

策略：

如下是ingress策略：

 ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379

有三种方式，分别是：

  1. ipBlock：匹配到的IP地址可以访问，except匹配到的无法访问 ；
  2. podSelector：指定匹配到label的pod能够访问；
  3. namespaceSelector：指定命名空间内任何pod能够访问。

其中podSelector默认作用于当前命名空间，如果想要作用于其他命名空间，可以这书写策略：取消掉列表。

    - namespaceSelector:
        matchLabels:
          project: myproject
      podSelector:
        matchLabels:
          role: frontend

egress策略同理。

测试1： 通过ingress策略的podSelector限制testpod无法访问pod1

修改策略文件：

[root@vms201 calico]# cat policy1.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy1
  namespace: network
spec:
  podSelector:
    matchLabels:
      test: pod1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: xxx
    ports:
    - protocol: TCP
      port: 80

作用于network命名空间中的node1，仅运行标签为role: xxx访问，作用的协议是TCP的80号端口。

[root@vms201 calico]# kubectl apply -f policy1.yaml
networkpolicy.networking.k8s.io/test-network-policy1 created
[root@vms201 calico]# kubectl get networkpolicies
NAME                   POD-SELECTOR   AGE
test-network-policy1   test=pod1      37s

应用策略后使用testpod进行验证：

[root@vms201 calico]# kubectl exec -it testpod -- sh
/home # curl svc1
/home # curl svc2
222

可以看到，目前testpod无法访问testpod。

测试完成后删除掉当前策略即可。

测试2： 通过egress策略的ipBlock限制testpod仅能访问通pod1，不能够访问pod2。

策略的yaml文件如下：

[root@vms201 calico]# cat policy2.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy2
spec:
  podSelector:
    matchLabels:
      run: testpod
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53
  - to:
    - ipBlock:
        cidr: 192.168.0.240/32
    ports:
    - protocol: TCP
      port: 80

作用于testpod上，192.168.0.240为pod1的IP地址。在其中加上namespaceSelector和允许protocol: UDP的原因是让其可以去访问kube-system空间内的DNS服务器，解析SVC的名称。

应用策略并查看结果：

[root@vms201 calico]# kubectl apply -f policy2.yaml
networkpolicy.networking.k8s.io/test-network-policy2 created
[root@vms201 calico]# kubectl get networkpolicies
NAME                   POD-SELECTOR   AGE
test-network-policy2   run=testpod    14s

进入testpod进行查看：

[root@vms201 calico]# kubectl exec -it testpod -- sh
/home # curl svc1
111
/home # curl svc2

默认策略：

默认拒绝所有入站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

默认允许所有入站流量：

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

默认拒绝所有出站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

默认允许所有出站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

默认拒绝所有入口和所有出站流量：

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

参考资料：
《老段CKA课程》

# 云计算 # k8s
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes