-
2020-11-20 10:18:03
前言：
在CentOS8中，我们常用的network.service服务就被NetworkManager.service服务代替了，同样的，IP的配置方法也发生了改变，那么如果想使用network.service服务去管理/配置系统网络怎么办呢？下面带你梦回network.service准备工作：
- 系统能连上网
一、禁用
NetworkManager.servicesystemctl stop NetworkManager systemctl disable NetworkManager执行结果：
[root@localhost ~]# systemctl stop NetworkManager [root@localhost ~]# systemctl disable NetworkManager Removed /etc/systemd/system/multi-user.target.wants/NetworkManager.service. Removed /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service. Removed /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service.到这里，
NetworkManager服务就停止工作了，这时候可以先安装network-scripts（也就是network.service)了二、安装
network-scripts静默安装(-q)
dnf install -y -q network-scripts安装过程:
[root@localhost ~]# dnf install -y -q network-scripts 警告：/var/cache/dnf/BaseOS-929b586ef1f72f69/packages/network-scripts-10.00.6-1.el8_2.1.x86_64.rpm: 头V3 RSA/SHA256 Signature, 密钥 ID 8483c65d: NOKEY 导入 GPG 公钥 0x8483C65D: Userid: "CentOS (CentOS Official Signing Key) <security@centos.org>" 指纹: 99DB 70FA E1D7 CE22 7FB6 4882 05B5 55B3 8483 C65D 来自: /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial [root@localhost ~]#此时，服务安装完成了，接下来开始启用该服务
启用之前再次确保NetworkManager关闭systemctl stop NetworkManager systemctl start network systemctl enable network systemctl status network执行结果：
[root@localhost ~]# systemctl stop NetworkManager [root@localhost ~]# systemctl start network [root@localhost ~]# systemctl enable network network.service is not a native service, redirecting to systemd-sysv-install. Executing: /usr/lib/systemd/systemd-sysv-install enable network [root@localhost ~]# systemctl status network ● network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network; generated) Active: active (running) since Fri 2020-07-03 12:49:02 EDT; 1min 46s ago Docs: man:systemd-sysv-generator(8) Tasks: 2 (limit: 11302) Memory: 10.2M CGroup: /system.slice/network.service ├─23350 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-37ed0dcd-4d32-4c1e-aaa1-6371494d4541-ens33.lease -pf /run/dhclient-ens33.pid ens33 └─23463 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-c87fa705-ed9f-4e03-b25a-142389898ff0-ens34.lease -pf /run/dhclient-ens34.pid ens34 7月 03 12:48:58 localhost network[23169]: 正在打开接口 ens34： 7月 03 12:48:58 localhost dhclient[23438]: Created duid "\000\004\305\214\015\204\360\376Az\212\354\216<g\262\342\374". 7月 03 12:48:58 localhost dhclient[23438]: DHCPDISCOVER on ens34 to 255.255.255.255 port 67 interval 6 (xid=0x986dfb66) 7月 03 12:48:59 localhost dhclient[23438]: DHCPREQUEST on ens34 to 255.255.255.255 port 67 (xid=0x986dfb66) 7月 03 12:48:59 localhost dhclient[23438]: DHCPOFFER from 10.1.1.254 7月 03 12:48:59 localhost dhclient[23438]: DHCPACK from 10.1.1.254 (xid=0x986dfb66) 7月 03 12:49:01 localhost dhclient[23438]: bound to 10.1.1.134 -- renewal in 847 seconds. 7月 03 12:49:01 localhost network[23169]: 正在确定 ens34 的 IP 信息... 完成。 7月 03 12:49:02 localhost network[23169]: [ 确定 ] 7月 03 12:49:02 localhost systemd[1]: Started LSB: Bring up/down networking.此时，
network服务已经启动成功了，那么下面就可以对NetworkManager进行卸载了。三、卸载
NetworkManager（可选）执行卸载命令：
dnf remove -y NetworkManager执行结果：
[root@localhost ~]# dnf remove -y NetworkManager 依赖关系解决。 ================================================================================================================================================================================================================================================== 软件包 架构 版本 仓库 大小 ================================================================================================================================================================================================================================================== 移除: NetworkManager x86_64 1:1.22.8-4.el8 @anaconda 8.6 M 移除依赖的软件包: NetworkManager-tui x86_64 1:1.22.8-4.el8 @anaconda 895 k cockpit x86_64 211.3-1.el8 @anaconda 53 k 清除未被使用的依赖关系: NetworkManager-libnm x86_64 1:1.22.8-4.el8 @anaconda 9.5 M NetworkManager-team x86_64 1:1.22.8-4.el8 @anaconda 52 k centos-logos x86_64 80.5-2.el8 @anaconda 699 k cockpit-bridge x86_64 211.3-1.el8 @anaconda 1.0 M cockpit-system noarch 211.3-1.el8 @anaconda 2.3 M cockpit-ws x86_64 211.3-1.el8 @anaconda 2.2 M glib-networking x86_64 2.56.1-1.1.el8 @anaconda 519 k gsettings-desktop-schemas x86_64 3.32.0-4.el8 @anaconda 4.0 M json-glib x86_64 1.4.4-1.el8 @anaconda 518 k libdaemon x86_64 0.14-15.el8 @anaconda 63 k libmodman x86_64 2.0.1-17.el8 @anaconda 68 k libndp x86_64 1.7-3.el8 @anaconda 79 k libnl3-cli x86_64 3.5.0-1.el8 @anaconda 819 k libproxy x86_64 0.4.15-5.2.el8 @anaconda 197 k libteam x86_64 1.29-1.el8 @anaconda 103 k network-scripts-team x86_64 1.29-1.el8 @BaseOS 6.6 k newt x86_64 0.52.20-11.el8 @anaconda 212 k slang x86_64 2.3.2-3.el8 @anaconda 1.3 M teamd x86_64 1.29-1.el8 @anaconda 271 k 事务概要 ================================================================================================================================================================================================================================================== 移除 22 软件包 将会释放空间：33 M 运行事务检查 事务检查成功。 运行事务测试 事务测试成功。 运行事务 准备中 : 1/1 运行脚本: NetworkManager-tui-1:1.22.8-4.el8.x86_64 1/1 删除 : NetworkManager-tui-1:1.22.8-4.el8.x86_64 1/22 删除 : cockpit-211.3-1.el8.x86_64 2/22 删除 : cockpit-system-211.3-1.el8.noarch 3/22 运行脚本: cockpit-ws-211.3-1.el8.x86_64 4/22 删除 : cockpit-ws-211.3-1.el8.x86_64 4/22 运行脚本: cockpit-ws-211.3-1.el8.x86_64 4/22 删除 : cockpit-bridge-211.3-1.el8.x86_64 5/22 删除 : glib-networking-2.56.1-1.1.el8.x86_64 6/22 删除 : NetworkManager-team-1:1.22.8-4.el8.x86_64 7/22 运行脚本: NetworkManager-1:1.22.8-4.el8.x86_64 8/22 删除 : NetworkManager-1:1.22.8-4.el8.x86_64 8/22 运行脚本: NetworkManager-1:1.22.8-4.el8.x86_64 8/22 删除 : teamd-1.29-1.el8.x86_64 9/22 运行脚本: teamd-1.29-1.el8.x86_64 9/22 删除 : libteam-1.29-1.el8.x86_64 10/22 运行脚本: libteam-1.29-1.el8.x86_64 10/22 删除 : newt-0.52.20-11.el8.x86_64 11/22 删除 : network-scripts-team-1.29-1.el8.x86_64 12/22 删除 : gsettings-desktop-schemas-3.32.0-4.el8.x86_64 13/22 删除 : centos-logos-80.5-2.el8.x86_64 14/22 运行脚本: centos-logos-80.5-2.el8.x86_64 14/22 删除 : libproxy-0.4.15-5.2.el8.x86_64 15/22 运行脚本: libproxy-0.4.15-5.2.el8.x86_64 15/22 删除 : libmodman-2.0.1-17.el8.x86_64 16/22 运行脚本: libmodman-2.0.1-17.el8.x86_64 16/22 删除 : slang-2.3.2-3.el8.x86_64 17/22 删除 : libnl3-cli-3.5.0-1.el8.x86_64 18/22 运行脚本: libnl3-cli-3.5.0-1.el8.x86_64 18/22 删除 : libdaemon-0.14-15.el8.x86_64 19/22 删除 : NetworkManager-libnm-1:1.22.8-4.el8.x86_64 20/22 运行脚本: NetworkManager-libnm-1:1.22.8-4.el8.x86_64 20/22 删除 : libndp-1.7-3.el8.x86_64 21/22 运行脚本: libndp-1.7-3.el8.x86_64 21/22 删除 : json-glib-1.4.4-1.el8.x86_64 22/22 运行脚本: json-glib-1.4.4-1.el8.x86_64 22/22 验证 : NetworkManager-1:1.22.8-4.el8.x86_64 1/22 验证 : NetworkManager-libnm-1:1.22.8-4.el8.x86_64 2/22 验证 : NetworkManager-team-1:1.22.8-4.el8.x86_64 3/22 验证 : NetworkManager-tui-1:1.22.8-4.el8.x86_64 4/22 验证 : centos-logos-80.5-2.el8.x86_64 5/22 验证 : cockpit-211.3-1.el8.x86_64 6/22 验证 : cockpit-bridge-211.3-1.el8.x86_64 7/22 验证 : cockpit-system-211.3-1.el8.noarch 8/22 验证 : cockpit-ws-211.3-1.el8.x86_64 9/22 验证 : glib-networking-2.56.1-1.1.el8.x86_64 10/22 验证 : gsettings-desktop-schemas-3.32.0-4.el8.x86_64 11/22 验证 : json-glib-1.4.4-1.el8.x86_64 12/22 验证 : libdaemon-0.14-15.el8.x86_64 13/22 验证 : libmodman-2.0.1-17.el8.x86_64 14/22 验证 : libndp-1.7-3.el8.x86_64 15/22 验证 : libnl3-cli-3.5.0-1.el8.x86_64 16/22 验证 : libproxy-0.4.15-5.2.el8.x86_64 17/22 验证 : libteam-1.29-1.el8.x86_64 18/22 验证 : network-scripts-team-1.29-1.el8.x86_64 19/22 验证 : newt-0.52.20-11.el8.x86_64 20/22 验证 : slang-2.3.2-3.el8.x86_64 21/22 验证 : teamd-1.29-1.el8.x86_64 22/22 已移除: NetworkManager-1:1.22.8-4.el8.x86_64 NetworkManager-libnm-1:1.22.8-4.el8.x86_64 NetworkManager-team-1:1.22.8-4.el8.x86_64 NetworkManager-tui-1:1.22.8-4.el8.x86_64 centos-logos-80.5-2.el8.x86_64 cockpit-211.3-1.el8.x86_64 cockpit-bridge-211.3-1.el8.x86_64 cockpit-system-211.3-1.el8.noarch cockpit-ws-211.3-1.el8.x86_64 glib-networking-2.56.1-1.1.el8.x86_64 gsettings-desktop-schemas-3.32.0-4.el8.x86_64 json-glib-1.4.4-1.el8.x86_64 libdaemon-0.14-15.el8.x86_64 libmodman-2.0.1-17.el8.x86_64 libndp-1.7-3.el8.x86_64 libnl3-cli-3.5.0-1.el8.x86_64 libproxy-0.4.15-5.2.el8.x86_64 libteam-1.29-1.el8.x86_64 network-scripts-team-1.29-1.el8.x86_64 newt-0.52.20-11.el8.x86_64 slang-2.3.2-3.el8.x86_64 teamd-1.29-1.el8.x86_64 完毕！ [root@localhost ~]#那么到这里，
NetworkManager服务就没了，然后我们使用network服务进行管理网络四、验证
network服务管理网络首先进入我们熟悉的路径：
cd /etc/sysconfig/network-scripts/ ls执行结果如下：
[root@localhost ~]# cd /etc/sysconfig/network-scripts/ [root@localhost network-scripts]# ls ifcfg-ens33 ifdown ifdown-ippp ifdown-post ifdown-tunnel ifup-bnep ifup-ipv6 ifup-plusb ifup-sit init.ipv6-global ifcfg-ens34 ifdown-bnep ifdown-ipv6 ifdown-routes ifup ifup-eth ifup-isdn ifup-post ifup-tunnel network-functions ifcfg-lo ifdown-eth ifdown-isdn ifdown-sit ifup-aliases ifup-ippp ifup-plip ifup-routes ifup-wireless network-functions-ipv6然后尝试更改IP地址:
此时，已经可以使用network服务进行管理IP了更多相关内容 -
lenet.network
2021-04-19 11:14:34OpenMV中训练好的lenet.network -
network in network 基于caffe的实现
2015-01-08 10:16:11network in network 基于caffe的实现, 一个是训练参数文件solver.prototxt, 一个是网络结构文件net.prototxt -
Foundations of Python Network Programming(3rd) 英文版pdf
2015-01-10 10:32:42Chapter 5: Network Data and Network Errors Chapter 6: TLS/SSL Chapter 7: Server Architecture Chapter 8: Caches and Message Queues Chapter 9: HTTP Clients Chapter 10: HTTP Servers Chapter ... -
ubuntu-network-manager-64位安装包
2013-07-15 21:37:14包含：plasma-widget-networkmanagement_0.9.0.8-0ubuntu1_amd64.deb，network-manager-kde_0.9.0.1-0ubuntu2_amd64.deb，network-manager_0.9.4.0-0ubuntu3_amd64.deb -
kubernetes networkpolicy网络策略详解
2020-09-05 19:17:13网络策略（NetworkPolicy）是一种关于 Pod 间及与其他网络端点间所允许的通信规则的规范。 NetworkPolicy 资源使用 标签 选择 Pod，并定义选定 Pod 所允许的通信规则。 2. 语法 apiVersion: networking.k8s.io/v1 ...展开全文kubernetes NetworkPolicy
tags: NetworkPolicy
文章目录
《美丽心灵》是关于20世纪伟大数学家小约翰•福布斯-纳什的人物传记片。
1. 简介
网络策略（NetworkPolicy）是一种关于 Pod 间及与其他网络端点间所允许的通信规则的规范。
NetworkPolicy 资源使用 标签 选择 Pod，并定义选定 Pod 所允许的通信规则。
2. 语法
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说明：
spec: NetworkPolicy 规约 中包含了在一个命名空间中定义特定网络策略所需的所有信息。podSelector: 每个 NetworkPolicy 都包括一个 podSelector ，它对该策略所应用的一组 Pod进行选择。示例中的策略选择带有"role=db" 标签的 Pod。空的 podSelector 选择命名空间下的所有 Pod。policyTypes: 每个 NetworkPolicy 都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。policyTypes 字段表示给定的策略是否应用于进入所选 Pod 的入口流量或者来自所选 Pod的出口流量，或两者兼有。如果 NetworkPolicy 未指定 policyTypes 则默认情况下始终设置 Ingress，如果NetworkPolicy 有任何出口规则的话则设置 Egress。ingress: 每个 NetworkPolicy 可包含一个 ingress 规则的白名单列表。每个规则都允许同时匹配from 和ports部分的流量。示例策略中包含一条简单的规则： 它匹配一个单一的端口，来自三个来源中的一个， 第一个通过 ipBlock指定，第二个通过namespaceSelector 指定，第三个通过 podSelector 指定。egress: 每个 NetworkPolicy 可包含一个 egress 规则的白名单列表。每个规则都允许匹配to 和 port部分的流量。该示例策略包含一条规则，该规则将单个端口上的流量匹配到 10.0.0.0/24 中的任何目的地。
所以，该网络策略示例:
- 隔离 “default” 命名空间下 “role=db” 的 Pod (如果它们不是已经被隔离的话)。
- （Ingress 规则）允许以下 Pod 连接到 “default” 命名空间下的带有 “role=db” 标签的所有 Pod 的
6379 TCP端口：
-
- “default” 命名空间下任意带有 “role=frontend” 标签的 Pod
-
- 带有 “project=myproject” 标签的任意命名空间中的 Pod
-
- IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了
172.17.1.0/24 之外的所有 172.17.0.0/16）
- IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了
- （Egress 规则）允许从带有 “role=db” 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978TCP 端口的连接。
3. 选择器 to 和 from 的行为
可以在 ingress from 部分或 egress to 部分中指定四种选择器：
第一种
podSelector: 这将在与 NetworkPolicy 相同的命名空间中选择特定的 Pod，应将其允许作为入口源或出口目的地。第二种
namespaceSelector: 这将选择特定的命名空间，应将所有 Pod 用作其输入源或输出目的地。第三种
namespaceSelector 和 podSelector: 一个指定 namespaceSelector 和 podSelector
的 to/from 条目选择特定命名空间中的特定 Pod。注意使用正确的 YAML 语法；这项策略：... ingress: - from: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: client ...在 from 数组中仅包含一个元素，只允许来自标有
role=client的 Pod 且该 Pod 所在的命名空间中标有user=alice的连接。但是 这项 策略：... ingress: - from: - namespaceSelector: matchLabels: user: alice - podSelector: matchLabels: role: client ...在 from 数组中包含两个元素，允许来自本地命名空间中标有
role=client的 Pod 的连接，或 来自任何命名空间中标有user = alice的任何 Pod 的连接。
这两种定义方式的区别，请你一定要分清楚。第四种：
ipBlock: 这将选择特定的IP CIDR范围以用作入口源或出口目的地。 这些应该是群集外部 IP，因为 Pod IP 存在时间短暂的且随机产生。
群集的入口和出口机制通常需要重写数据包的源 IP 或目标 IP。在发生这种情况的情况下，不确定在 NetworkPolicy 处理之前还是之后发生，并且对于网络插件，云提供商，Service 实现等的不同组合，其行为可能会有所不同。在进入的情况下，这意味着在某些情况下，您可以根据实际的原始源 IP 过滤传入的数据包，而在其他情况下，NetworkPolicy 所作用的 源IP 则可能是 LoadBalancer 或 Pod 的节点等。
对于出口，这意味着从 Pod 到被重写为集群外部 IP 的 Service IP 的连接可能会或可能不会受到基于 ipBlock 的策略的约束
4. 默认策略
默认情况下，如果命名空间中不存在任何策略，则所有进出该命名空间中的 Pod 的流量都被允许。以下示例使您可以更改该命名空间中的默认行为。
4.1 默认拒绝所有入口流量
您可以通过创建选择所有容器但不允许任何进入这些容器的入口流量的 NetworkPolicy 来为命名空间创建 “default” 隔离策略。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress spec: podSelector: {} policyTypes: - Ingress这样可以确保即使容器没有选择其他任何
NetworkPolicy，也仍然可以被隔离。此策略不会更改默认的出口隔离行为。4.2 默认允许所有入口流量
如果要允许所有流量进入某个命名空间中的所有 Pod（即使添加了导致某些 Pod 被视为“隔离”的策略），则可以创建一个策略来明确允许该命名空间中的所有流量。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-ingress spec: podSelector: {} ingress: - {} policyTypes: - Ingress4.3 默认拒绝所有出口流量
您可以通过创建选择所有容器但不允许来自这些容器的任何出口流量的 NetworkPolicy 来为命名空间创建 “default” egress 隔离策略。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-egress spec: podSelector: {} policyTypes: - Egress4.4 默认允许所有出口流量
如果要允许来自命名空间中所有 Pod 的所有流量（即使添加了导致某些 Pod 被视为“隔离”的策略），则可以创建一个策略，该策略明确允许该命名空间中的所有出口流量。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress spec: podSelector: {} egress: - {} policyTypes: - Egress4.5 默认拒绝所有入口和所有出口流量
您可以为命名空间创建 “default” 策略，以通过在该命名空间中创建以下 NetworkPolicy 来阻止所有入站和出站流量。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: - Ingress - Egress5. 实战示例
5.1 创建一个nginx Deployment 并且通过服务将其暴露
$ kubectl create deployment nginx --image=nginx $ kubectl expose deployment nginx --port=80 #此 Deployment 以名为 nginx 的 Service 暴露出来 $ kubectl get svc,pod $ kubectl run busybox --rm -ti --image=busybox /bin/sh # 创建测试工具的pod $ wget --spider --timeout=1 nginx Connecting to nginx (10.100.0.16:80) remote file exists5.2 限制 nginx 服务的访问
如果想限制对 nginx 服务的访问，只让那些拥有标签
access: true的 Pod 访问它， 那么可以创建一个如下所示的 NetworkPolicy 对象：apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-nginx spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: access: "true"注意： NetworkPolicy 中包含选择策略所适用的 Pods 集合的
podSelector。 你可以看到上面的策略选择的是带有标签 app=nginx 的 Pods。 此标签是被自动添加到 nginx Deployment 中的 Pod 上的。 如果 podSelector 为空，则意味着选择的是名字空间中的所有 Pods。$ kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml $ kubectl run busybox --rm -ti --image=busybox -- /bin/sh #创建测试工具的pod $ wget --spider --timeout=1 nginx Connecting to nginx (10.100.0.16:80) wget: download timed out 定义访问标签后再次测试 创建一个拥有正确标签的 Pod，你将看到请求是被允许的： $ kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh 在 Shell 中运行命令： $ wget --spider --timeout=1 nginx Connecting to nginx (10.100.0.16:80) remote file exists6. networkpolicy原理
在具体实现上，凡是支持 NetworkPolicy 的 CNI 网络插件，都维护着一个 NetworkPolicy Controller，通过控制循环的方式对 NetworkPolicy 对象的增删改查做出响应，然后在宿主机上完成 iptables 规则的配置工作。
在 Kubernetes 生态里，目前已经实现了 NetworkPolicy 的网络插件包括
Calico、Weave和kube-router等多个项目，但是并不包括Flannel项目。所以说，如果想要在使用 Flannel 的同时还使用 NetworkPolicy 的话，你就需要再额外安装一个网络插件，比如 Calico 项目，来负责执行 NetworkPolicy。安装 Flannel + Calico 的流程非常简单，你直接参考这个文档一键安装即可。
那么，这些网络插件，又是如何根据 NetworkPolicy 对 Pod 进行隔离的呢？
接下来，我就以三层网络插件为例（比如 Calico 和 kube-router），来为你分析一下这部分的原理。为了方便讲解，这一次我编写了一个比较简单的 NetworkPolicy 对象，如下所示：
apiVersion: extensions/v1beta1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: tcp port: 6379可以看到，我们指定的 ingress“白名单”，是任何 Namespace 里，携带 project=myproject 标签的 Namespace 里的 Pod；以及 default Namespace 里，携带了 role=frontend 标签的 Pod。允许被访问的端口是：6379。
而被隔离的对象，是所有携带了 role=db 标签的 Pod。
那么这个时候，Kubernetes 的网络插件就会使用这个 NetworkPolicy 的定义，在宿主机上生成 iptables 规则。这个过程，我可以通过如下所示的一段 Go 语言风格的伪代码来为你描述：
for dstIP := range 所有被networkpolicy.spec.podSelector选中的Pod的IP地址 for srcIP := range 所有被ingress.from.podSelector选中的Pod的IP地址 for port, protocol := range ingress.ports { iptables -A KUBE-NWPLCY-CHAIN -s $srcIP -d $dstIP -p $protocol -m $protocol --dport $port -j ACCEPT } } }可以看到，这是一条最基本的、通过匹配条件决定下一步动作的 iptables 规则。这条规则的名字是
KUBE-NWPLCY-CHAIN，含义是：当 IP 包的源地址是srcIP、目的地址是dstIP、协议是protocol、目的端口是port的时候，就允许它通过（ACCEPT）。而正如这段伪代码所示，匹配这条规则所需的这四个参数，都是从 NetworkPolicy 对象里读取出来的。
可以看到，Kubernetes 网络插件对 Pod 进行隔离，其实是靠在宿主机上生成 NetworkPolicy 对应的 iptable 规则来实现的。
此外，在设置好上述“隔离”规则之后，网络插件还需要想办法，将所有对被隔离 Pod 的访问请求，都转发到上述
KUBE-NWPLCY-CHAIN规则上去进行匹配。并且，如果匹配不通过，这个请求应该被“拒绝”。在 CNI 网络插件中，上述需求可以通过设置两组 iptables 规则来实现。
第一组规则，负责“拦截”对被隔离 Pod 的访问请求。生成这一组规则的伪代码，如下所示：
for pod := range 该Node上的所有Pod { if pod是networkpolicy.spec.podSelector选中的 { iptables -A FORWARD -d $podIP -m physdev --physdev-is-bridged -j KUBE-POD-SPECIFIC-FW-CHAIN iptables -A FORWARD -d $podIP -j KUBE-POD-SPECIFIC-FW-CHAIN ... } }可以看到，这里的的 iptables 规则使用到了内置链：
FORWARD。它是什么意思呢？说到这里，我就得为你稍微普及一下 iptables 的知识了。实际上，iptables 只是一个操作 Linux 内核
Netfilter子系统的“界面”。顾名思义，Netfilter 子系统的作用，就是 Linux 内核里挡在“网卡”和“用户态进程”之间的一道“防火墙”。它们的关系，可以用如下的示意图来表示：
可以看到，这幅示意图中，IP 包“一进一出”的两条路径上，有几个关键的“检查点”，它们正是 Netfilter 设置“防火墙”的地方。在 iptables 中，这些“检查点”被称为：链（Chain）。这是因为这些“检查点”对应的 iptables 规则，是按照定义顺序依次进行匹配的。这些“检查点”的具体工作原理，可以用如下所示的示意图进行描述：
可以看到，当一个 IP 包通过网卡进入主机之后，它就进入了Netfilter定义的流入路径（Input Path）里。在这个路径中，IP 包要经过路由表路由来决定下一步的去向。而在这次路由之前，Netfilter 设置了一个名叫PREROUTING的“检查点”。在 Linux 内核的实现里，所谓“检查点”实际上就是内核网络协议栈代码里的 Hook（比如，在执行路由判断的代码之前，内核会先调用 PREROUTING 的 Hook）。
而在经过路由之后，IP 包的去向就分为了两种：- 第一种，继续在本机处理；
- 第二种，被转发到其他目的地。
我们先说一下 IP 包的第一种去向。这时候，IP 包将继续向上层协议栈流动。在它进入传输层之前，Netfilter 会设置一个名叫 INPUT 的“检查点”。到这里，IP 包流入路径（Input Path）结束。接下来，这个 IP 包通过传输层进入用户空间，交给用户进程处理。而处理完成后，用户进程会通过本机发出返回的 IP 包。这时候，这个 IP 包就进入了流出路径（Output Path）。
此时，IP 包首先还是会经过主机的路由表进行路由。路由结束后，Netfilter 就会设置一个名叫 OUTPUT 的“检查点”。然后，在 OUTPUT 之后，再设置一个名叫 POSTROUTING“检查点”。你可能会觉得奇怪，为什么在流出路径结束后，Netfilter 会连着设置两个“检查点”呢？
这就要说到在流入路径里，路由判断后的第二种去向了。在这种情况下，这个 IP 包不会进入传输层，而是会继续在网络层流动，从而进入到转发路径（Forward Path）。在转发路径中，Netfilter 会设置一个名叫 FORWARD 的“检查点”。而在 FORWARD“检查点”完成后，IP 包就会来到流出路径。而转发的 IP 包由于目的地已经确定，它就不会再经过路由，也自然不会经过 OUTPUT，而是会直接来到 POSTROUTING“检查点”。所以说，POSTROUTING 的作用，其实就是上述两条路径，最终汇聚在一起的“最终检查点”。
需要注意的是，在有网桥参与的情况下，上述 Netfilter 设置“检查点”的流程，实际上也会出现在链路层（二层），并且会跟我在上面讲述的网络层（三层）的流程有交互。这些链路层的“检查点”对应的操作界面叫作
ebtables。所以，准确地说，数据包在 Linux Netfilter 子系统里完整的流动过程，其实应该如下所示:
以看到，我前面为你讲述的，正是上图中绿色部分，也就是网络层的 iptables 链的工作流程。另外，你应该还能看到，每一个白色的“检查点”上，还有一个绿色的“标签”，比如：raw、nat、filter 等等。在 iptables 里，这些标签叫作：表。比如，同样是 OUTPUT 这个“检查点”，filter Output 和 nat Output 在 iptables 里的语法和参数，就完全不一样，实现的功能也完全不同。所以说，iptables 表的作用，就是在某个具体的“检查点”（比如 Output）上，按顺序执行几个不同的检查动作（比如，先执行 nat，再执行 filter）.在理解了 iptables 的工作原理之后，我们再回到 NetworkPolicy 上来。这时候，前面由网络插件设置的、负责“拦截”进入 Pod 的请求的三条 iptables 规则，就很容易读懂了：
iptables -A FORWARD -d $podIP -m physdev --physdev-is-bridged -j KUBE-POD-SPECIFIC-FW-CHAIN iptables -A FORWARD -d $podIP -j KUBE-POD-SPECIFIC-FW-CHAIN ...其中，第一条 FORWARD 链“拦截”的是一种特殊情况：它对应的是同一台宿主机上容器之间经过 CNI 网桥进行通信的流入数据包。其中，
--physdev-is-bridged的意思就是，这个FORWARD 链匹配的是，通过本机上的网桥设备，发往目的地址是 podIP 的 IP 包。当然，如果是像 Calico 这样的非网桥模式的 CNI 插件，就不存在这个情况了。
kube-router其实是一个简化版的 Calico，它也使用 BGP 来维护路由信息，但是使用 CNI bridge 插件负责跟 Kubernetes 进行交互。而第二条 FORWARD 链“拦截”的则是最普遍的情况，即：容器跨主通信。这时候，流入容器的数据包都是经过路由转发（FORWARD 检查点）来的。
不难看到，这些规则最后都跳转（即：-j）到了名叫
KUBE-POD-SPECIFIC-FW-CHAIN的规则上。它正是网络插件为 NetworkPolicy 设置的第二组规则。而这个
KUBE-POD-SPECIFIC-FW-CHAIN的作用，就是做出“允许”或者“拒绝”的判断。这部分功能的实现，可以简单描述为下面这样的 iptables 规则：iptables -A KUBE-POD-SPECIFIC-FW-CHAIN -j KUBE-NWPLCY-CHAIN iptables -A KUBE-POD-SPECIFIC-FW-CHAIN -j REJECT --reject-with icmp-port-unreachable可以看到，首先在第一条规则里，我们会把 IP 包转交给前面定义的 KUBE-NWPLCY-CHAIN 规则去进行匹配。按照我们之前的讲述，如果匹配成功，那么 IP 包就会被“允许通过”。而如果匹配失败，IP 包就会来到第二条规则上。可以看到，它是一条 REJECT 规则。通过这条规则，不满足 NetworkPolicy 定义的请求就会被拒绝掉，从而实现了对该容器的“隔离”。
以上，就是 CNI 网络插件实现 NetworkPolicy 的基本方法了。
7. 总结
- Kubernetes 对 Pod 进行“隔离”的手段，即：NetworkPolicy。
而基于上述讲述，你就会发现这样一个事实：
Kubernetes 的网络模型以及大多数容器网络实现，其实既不会保证容器之间二层网络的互通，也不会实现容器之间的二层网络隔离。这跟 IaaS 项目管理虚拟机的方式，是完全不同的。所以说，Kubernetes 从底层的设计和实现上，更倾向于假设你已经有了一套完整的物理基础设施。然后，Kubernetes 负责在此基础上提供一种“
弱多租户”（soft multi-tenancy）的能力。并且，基于上述思路，Kubernetes 将来也不大可能把 Namespace 变成一个具有实质意义的隔离机制，或者把它映射成为“子网”或者“租户”。毕竟你可以看到，NetworkPolicy 对象的描述能力，要比基于 Namespace 的划分丰富得多。这也是为什么，到目前为止，Kubernetes 项目在云计算生态里的定位，其实是基础设施与 PaaS 之间的中间层。这是非常符合“容器”这个本质上就是进程的抽象粒度的。当然，随着 Kubernetes 社区以及 CNCF 生态的不断发展，Kubernetes 项目也已经开始逐步下探，“吃”掉了基础设施领域的很多“蛋糕”。这也正是容器生态继续发展的一个必然方向。
参考：
-
机器学习笔记 network compression
2022-03-07 11:33:57我们为什么要进行network compression呢？ 因为在某些环境中（比如在手机，手环等设备中），如果我们要嵌入深度学习model的话，那么鉴于设备的原因，其存储空间，或是计算能力，都是有限的。所以我们不能需要太大的...展开全文来自于李宏毅教授的ML课件，作业七部分
0 前言
我们为什么要进行network compression呢？
因为在某些环境中（比如在手机，手环等设备中），如果我们要嵌入深度学习model的话，那么鉴于设备的原因，其存储空间，或是计算能力，都是有限的。所以我们不能需要太大的模型。
1 network pruning
对于很大的模型来说，并不是它的所有参数都是有用的，我们也许不需要那么多的参数
以人脑神经元的pruning过程为例，人脑也是在成长过程中先是有很多的神经元连接，然后慢慢地将冗余的神经元连接去掉
比如我们以用L1范数评估weight的重要性为例：
我们现在有3个filter（橙、蓝、绿），我们通过计算这三个filter的L1范数，判断各个filter权重的重要性，把小的那个去掉
1.1 为什么不一开始train一个小模型
那么问题来了：为什么不一开始就trian一个小的network呢？而是要从一个大的network再慢慢地prune成一个小model呢
因为如果只是一个小模型的话，可能会遇到鞍点或者局部最小值，不一定能learn得很好。但是大模型的话（尤其是足够大的模型），是可以避开鞍点和local minimal的
1.1.1 lottery ticket hypothesis
这是19ICLR的一篇paper，大致意思是这样的
对于一个大模型，我首先随机初始化一组参数（红色部分），然后进行tuning，得到效果还不错的模型（紫色部分）
之后我们进行model pruning，得到一个小一点的模型（但是剩下的这些部分参数不变，仍然为紫色的部分）
此时如果我们对剩下的模型部分重新随机初始化（绿色部分），可能是learn不出一个很好的模型的。但是如果我们将原来随机初始化大模型对应的参数直接复制过来，是可以train得不错的
1.2 network pruning 实际操作上的选择
如果我们是weight pruning，那么这会使得模型不易实现，也不易用GPU加速
- 因为这样的话模型就不是一个矩阵的形式，那么无论是pytorch这种深度学习框架，还是依靠矩阵运算来加速的GPU，都无法实现
- 如果我们只是将prune的weight用0表示，那么模型参数的规模还是不变的
如果我们是neuron pruning，那么我们只是减掉矩阵的一定的维度，依然很方便地实现&GPU加速
2 knowledge distillation
在知识蒸馏中，我们的目标是train一个大的network（teacher network）和一个小的network（student network）。其中teacher network学习的label就是ground truth的label，而小的student network所需要学习的内容是teacher network的输出
这样的好处在哪里呢？相比于一个冷冰冰的ground label 1，teacher network可以学到这个label更丰富的信息（比如7和9这两个数字跟1很像，同时7比9更像）
——>这样就会导致，哪怕student没有看到过7和9，他也有可能learn出一定的7&9的特征
——>teacher network 往往是一个很大的/集成了很多模型的大model，student network则可以用较少的参数实现近似的效果
2.1 label temperature
由于知识蒸馏希望teacher学习到更丰富的信息，不希望他仅仅学习到（接近）one-hot label的信息，所以我们希望各个label之间的差距稍微拉近一些，这时候就需要用到temperature的内容
2.2 TA network
如果teacher network 和student network 相差太大，那么student network可能没法很好地学习teacher network
于是引入一个参数量介于teacher network和student network之间的TA networl 来帮助student network 学习
3 parameter quantization
有两种思路：
第一种是使用更少的比特数来表示一个参数值
第二种是进行weight clustering
比如我们根据某种clustering的方法把weight分成四个cluster，每个cluster的weight值都使用这个cluster的平均值来表示
这样的好处是省内存，我们只需要一个记录每个cluster是什么数值的table，以及一个元素为属于哪个cluster的矩阵就可以了（比如我们分成四个cluster，只需要2bit）
但是这种方法势必会减少一定的精度
第三种方法是使用类似于哈夫曼编码的方式进行编码
使用比较频繁weight用较少的比特表示，使用比较少的weight用较多的比特表示
4 模型架构设计
比如，我们本来想创建一个N维到M维的全连接层，我们需要M*N个参数
现在我们在中间插入一层维度为K的中间层，那么我们只需要M*K+N*K个参数
包括mobilenet，就是一种很明显的依靠模型架构设计的方法来进行
NTU 课程 7454 （5） CNN进阶_UQI-LIUWJ的博客-CSDN博客
5 动态计算
如果资源充足的时候，那么就做到最好；如果资源不足的时候，那么就在不怎么影响性能的情况下，先求有再求好【类似于省电模式】
一种解决方法是，在中间的hidden layer 就接一些输出，如果计算资源不足的时候，那么从中间就把结果输出出来了
6 多种network compression方法混合
-
ubuntu 12.04 中network-manager 离线安装包
2012-10-17 14:46:24如果卸载了network-manager,就无法再上网进行 apt-get install，可下载离线包u盘考入后，dpkg -i *.deb就回来了。 ubuntu 12中有线网无法设static ip，可先卸载network-manager,再修改eth0配置，重新安装network-... -
EPSON EasyMP Network Projection for Windows 应用软件
2014-04-26 16:31:39EPSON的无线投影软件，只需支持EPSON无线投影的投影机都可以使用，脱离有线烦恼。 -
hp usb network print adapter 驱动程序软件
2013-05-20 10:01:53用于HP网络打印机的适配器 hp usb network print adapter 驱动程序软件 -
Microsoft Network Monitor的select network栏空白
2022-03-29 22:20:06select network栏空白，把软件Microsoft Network Monitor卸载了，重新安装一遍。展开全文今天搞了一下午的网络适配器，终于弄好了，我觉得大概是之前在用虚拟机的时候把虚拟机错误桥接的原因大有关系。到了晚上用monitor的时候发现select network栏无论如何都是空白的，本以为是外置网卡没有插上的缘故，插了也没用。
当时大概的情况就是这样（现在已经解决）
解决方法：
把软件Microsoft Network Monitor卸载了，重新安装一遍。
原因：
monitor软件是昨天下载的，昨天情况还是正常的，但是今天早上我的网络适配器出现了问题（错误56），导致我的真实无线网卡和Realtek都没法上网了，下午折腾了好一会儿才找到解决方案（下一个ccclean把注册表清理干净），之前拿着错误的网卡配置下载的软件，跟着数据也就错了，所以select network也就没有了。
第一次写博客，好紧张，当做是记录平时的一些问题解决过程吧。
-
docker network详解、教程
2020-12-14 16:30:33dokcer network 详解、教程1、docker network --help2、创建自定义docker局域网络3、pull镜像和运行镜像4、docker 查询网络信息5、验证ping命令是否容器之间网络交互6、使用docker network connect7、docker network... -
浏览器控制台Network面板简述
2021-09-01 15:24:24浏览器控制台Network面板简述如何打开NetWork面板控制台Network的作用面板组成请求列表请求列表每列：查看单个资源的详细信息查看HTTP头信息General部分：Response Headers（响应头）部分:Request Headers （请求头... -
OpenWrt network 启动过程
2020-06-03 12:31:17小结 - 网络配置文件 /etc/config/network - 网络初始化脚本/etc/init.d/network - swconfig 用于配置 switch - netifd 进行更复杂的网络管理，创建虚拟网卡，dhcp 等 -
我对Pi Network的Pi币价格的预测
2020-11-11 12:43:48在对Pi Network的Pi币价格预估之前，先讨论一下在经济学里关于价格的决定因素。关于价格的决定因素，有两种观点： 1 价值决定价格 2 供求关系决定价格 对于这两种观点的讨论，有一篇有意思的帖子 ... -
F2DNet: Fast Focal Detection Network for Pedestrian Detection
2022-03-19 21:16:54论文标题:F2DNet: Fast Focal Detection Network for Pedestrian Detection 论文地址:https://arxiv.org/abs/2203.02331 论文源码:https://github.com/AbdulHannanKhan/F2DNet. 凯撒斯劳滕工业大学 CVPR2022 ... -
Broadcom 802.11ac Network Adapter驱动
2014-03-04 21:21:25Broadcom 802.11ac Network Adapter驱动 适用于win7，win8，win8.1 -
openwrt之network配置文件
2021-02-02 10:50:45config network,主要负责网络接口的配置 openwrt 19.07.04 netowrk 配置文件 root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ip... -
（三）HyperLedger Fabric 2.x test-network搭建测试网络
2021-12-30 20:15:06本文默认HyperLedger Fabric 2.x环境已经搭好且启动 test-network 网络测试完成。 如果在启动 test-network 网络测试的过程中出现错误问题，可参考我这篇博客： HyperLedger Fabric 2.x 启动test-network测试网络... -
juniper-networks-network-connect
2013-05-26 00:45:56juniper-networks-network-connect. -
Restarting network (via systemctl): Job for network.service failed because the control pr
2022-02-20 10:44:49Restarting network (via systemctl): Job for network.service failed because the control pr 困惑了好久的问题：使用vmware 的 centos7 突然不知为何 不能上网。 重新启动网络 service network restart 遇到如下... -
EFI Network…
2022-03-21 17:34:56在VMware虚拟机上安装Windows时提示EFI Network的问题（Mac系统） 在VMware上创建Windows10虚拟机，安装镜像为ISO格式，启动后报错，显示EFI Network…，如图所示 解决方法：将默认的UEFI格式设置为BIOS格式，更换... -
Network security configuration
2021-11-01 15:50:53Network security configuration https://developer.android.com/training/articles/security-config#CertificatePinning 二. 理解 1.Android客户端应用,通过信任系统预装的CAs,使用其公钥来验签,该CA颁发的证书. ... -
network-scripts目录下添加新网卡文件方法、nmcli修改NAME网卡名称和DEVICE一致
2021-06-01 11:31:18文章目录说明添加网卡文件方式1【不建议用】添加网卡文件方式2【建议用】 ...[root@controll network-scripts]# ifconfig |grep ens ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 en -
network is unreachable
2021-04-26 17:54:32Linux7配置网络报错：network is unreachable 一般有一下几个原因： 1、ip（IPADDR）网关（GATEWAY）子网掩码（NETMASK）等参数配置问题 2、网卡配置中：ONBOOT参数问题，改为（ONBOOT=“yes”） 3、/etc/sysconfig... -
USB Network Gate SDK Crack,构建USB Network Gate的技术
2022-01-21 23:42:26USB Network Gate SDK Crack,构建USB Network Gate的技术 USB Network Gate SDK是一个灵活的软件包，它为希望通过额外功能增强其应用程序的开发人员整合了大量资源。 USB Network Gate SDK Crack企鹅... -
docker network create
2020-09-21 10:27:37一、简介 Docker有以下网络类型： bridge：多由于独立container之间的通信 host： 直接使用宿主机的网络，端口也使用宿主机的 overlay：当有多个docker主机时，...CNyteng:docker-volume yteng$ docker network ls NETW -
RedHat系统NetworkManage网络管理工具简介及相关命令（lspci、lshw）
2021-08-08 19:14:38在早期的Linux发行版本中几乎所有的网络服务都是network服务，从RHEL7开始，红帽官方建议采用NetworkManage方式配置网络，而不建议再使用network服务这种传统的方式配置网络。因为网络是非常复杂的，需要配置的网络... -
虚拟USB共享USB OVER NETWORK 5.0.2WIN平台 有注册码
2013-11-23 09:29:29支持WINXP,WIN7,WIN8,WIN8.1 SERVER2003/2008/2008R2/2012 R2，中文版不稳定故上传的为英文原版，包含了32位，64位安装包 -
Deeper Network主网成功上线，迎接Web3.0的大浪潮！
2021-08-29 14:54:19太平洋时间8月28日上午11：00，Deeper Network主网Deeper Chain正式上线，开启了Deeper Network发展的新篇章，作为Web3.0基础设施，Deeper Network代表了世界上第一个去中心化分布式区块链网络，获得了机构和社区的...
