网站运营编辑做什么的,wordpress搬家后台还是老网站,找回老网站,系统开发是什么Kubernetes 中#xff0c;Network Policy#xff08;网络策略#xff09;定义了一组 Pod 是否允许相互通信#xff0c;或者与网络中的其他端点 endpoint 通信。
NetworkPolicy 对象使用标签选择Pod#xff0c;并定义规则指定选中的Pod可以执行什么样的网络通信#xff0…Kubernetes 中Network Policy网络策略定义了一组 Pod 是否允许相互通信或者与网络中的其他端点 endpoint 通信。
NetworkPolicy 对象使用标签选择Pod并定义规则指定选中的Pod可以执行什么样的网络通信规则通常由如下三类信息组合而成
允许访问的其他容器组容器组不能阻止其访问自己的端口允许访问的名称空间允许访问的 IP 段例外从容器组所在的节点访问容器组或者从容器组访问其所在的节点都是始终被允许的
前提条件
Network Policy 由网络插件实现因此您使用的网络插件必须能够支持 NetworkPolicy 才可以使用此特性。如果您仅仅是创建了一个 Network Policy 对象但是您使用的网络插件并不支持此特性您创建的 Network Policy 对象是不生效的。
Isolated/Non-isolated Pods·
默认情况下Pod 都是非隔离的non-isolated可以接受来自任何请求方的网络请求。
如果一个 NetworkPolicy 的标签选择器选中了某个 Pod则该 Pod 将变成隔离的isolated并将拒绝任何不被 NetworkPolicy 许可的网络连接。名称空间中其他未被 NetworkPolicy 选中的 Pod 将认可接受来自任何请求方的网络请求。
Network Police 不会相互冲突而是相互叠加的。如果多个 NetworkPolicy 选中了同一个 Pod则该 Pod 可以接受这些 NetworkPolicy 当中任何一个 NetworkPolicy 定义的入口/出口规则是所有NetworkPolicy规则的并集因此NetworkPolicy 的顺序并不重要因为不会影响到最终的结果。
为了使两个容器组之间的网络能够连通源容器组的出方向网络策略和目标容器组的入方向无网络策略必须同时允许该网络连接。只要其中的任何一方拒绝了该连接该连接都不能创建成功。
NetworkPolicy对象
参阅 NetworkPolicy 来了解资源的完整定义。
下面是一个 NetworkPolicy 的示例:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: test-network-policynamespace: default
spec:podSelector:matchLabels:role: dbpolicyTypes:- Ingress- Egressingress:- from:- ipBlock:cidr: 172.17.0.0/16except:- 172.17.1.0/24- namespaceSelector:matchLabels:project: myproject- podSelector:matchLabels:role: frontendports:- protocol: TCPport: 6379egress:- to:- ipBlock:cidr: 10.0.0.0/24ports:- protocol: TCPport: 5978基本信息 同其他的 Kubernetes 对象一样NetworkPolicy 需要 apiVersion、kind、metadata 字段specNetworkPolicy 的 spec字段包含了定义网络策略的主要信息 podSelector 同名称空间中符合此标签选择器 .spec.podSelector 的 Pod 都将应用这个 NetworkPolicy。上面的 Example中的 podSelector 选择了 roledb 的 Pod。如果该字段为空则将对名称空间中所有的 Pod 应用这个 NetworkPolicypolicyTypes .spec.policyTypes 是一个数组类型的字段该数组中可以包含 Ingress、Egress 中的一个也可能两个都包含。该字段标识了此 NetworkPolicy 是否应用到 入方向的网络流量、出方向的网络流量、或者两者都有。如果不指定 policyTypes 字段该字段默认将始终包含 Ingress当 NetworkPolicy 中包含出方向的规则时Egress 也将被添加到默认值。ingressingress是一个数组代表入方向的白名单规则。每一条规则都将允许与from 和ports匹配的入方向的网络流量发生。例子中的ingress包含了一条规则允许的入方向网络流量必须符合如下条件 Pod 的监听端口为 6379请求方可以是如下三种来源当中的任意一种 ipBlock 为 172.17.0.0/16 网段但是不包括 172.17.1.0/24 网段namespaceSelector 标签选择器匹配标签为 projectmyprojectpodSelector 标签选择器匹配标签为 rolefrontend egressegress是一个数组代表出方向的白名单规则。每一条规则都将允许与to和ports匹配的出方向的网络流量发生。例子中的egress允许的出方向网络流量必须符合如下条件 目标端口为 5978目标 ipBlock 为 10.0.0.0/24 网段
因此例子中的 NetworkPolicy 对网络流量做了如下限制
隔离了 default 名称空间中带有 roledb 标签的所有 Pod 的入方向网络流量和出方向网络流量Ingress规则入方向白名单规则 当请求方是如下三种来源当中的任意一种时允许访问default名称空间中所有带roledb标签的 Pod 的6379端口 ipBlock 为 172.17.0.0/16 网段但是不包括 172.17.1.0/24 网段namespaceSelector 标签选择器匹配标签为 projectmyprojectpodSelector 标签选择器匹配标签为 rolefrontend Egress rules出方向白名单规则 当如下条件满足时允许出方向的网络流量 目标端口为 5978目标 ipBlock 为 10.0.0.0/24 网段
to和from选择器的行为
NetworkPolicy 的 .spec.ingress.from 和 .spec.egress.to 字段中可以指定 4 种类型的标签选择器 podSelector 选择与 NetworkPolicy 同名称空间中的 Pod 作为入方向访问控制规则的源或者出方向访问控制规则的目标 namespaceSelector 选择某个名称空间其中所有的Pod作为入方向访问控制规则的源或者出方向访问控制规则的目标 namespaceSelector 和 podSelector 在一个 to / from 条目中同时包含 namespaceSelector 和 podSelector 将选中指定名称空间中的指定 Pod。此时请特别留意 YAML 的写法如下所示 ...ingress:- from:- namespaceSelector:matchLabels:user: alicepodSelector:matchLabels:role: client...该例子中podSelector 前面没有 - 减号namespaceSelector 和 podSelector 是同一个 from 元素的两个字段将选中带 useralice 标签的名称空间中所有带 roleclient 标签的 Pod。但是下面的这个 NetworkPolicy 含义是不一样的 ...ingress:- from:- namespaceSelector:matchLabels:user: alice- podSelector:matchLabels:role: client... 后者podSelector 前面带 - 减号说明 namespaceSelector 和 podSelector 是 from 数组中的两个元素他们将选中 NetworkPolicy 同名称空间中带 roleclient 标签的对象以及带 useralice 标签的名称空间的所有 Pod。 当您对此不确信时可以尝试使用 kubectl describe 命令查看 kubernetes 是如何解析您定义的 NetworkPolicy 的。 ipBlock 可选择 IP CIDR 范围作为入方向访问控制规则的源或者出方向访问控制规则的目标。这里应该指定的是集群外部的 IP因为集群内部 Pod 的 IP 地址是临时分配的且不可预测。 集群的入方向和出方向网络机制通常需要重写网络报文的 source 或者 destination IP。kubernetes 并未定义应该在处理 NetworkPolicy 之前还是之后再修改 source / destination IP因此在不同的云供应商、使用不同的网络插件时最终的行为都可能不一样。这意味着 对于入方向的网络流量某些情况下你可以基于实际的源 IP 地址过滤流入的报文在另外一些情况下NetworkPolicy 所处理的 “source IP” 可能是 LoadBalancer 的 IP 地址或者其他地址对于出方向的网络流量基于 ipBlock 的策略可能有效也可能无效
