需要做网站的企业电话,百度安装免费下载,vuepress wordpress,怎么申请 免费网站空间一、Network Policy 是什么,在云原生领域有和作用
Network Policy 是 Kubernetes 官方提出来的一种网络策略的规范#xff0c;用户通过编写符合对应规范的规则来控制 k8s 集群内 L3 和 L4 层的网络流量。
NetworkPolicy 主要的功能就是实现在云原生领域的容器网络管控它给用…一、Network Policy 是什么,在云原生领域有和作用
Network Policy 是 Kubernetes 官方提出来的一种网络策略的规范用户通过编写符合对应规范的规则来控制 k8s 集群内 L3 和 L4 层的网络流量。
NetworkPolicy 主要的功能就是实现在云原生领域的容器网络管控它给用户提供了几点最常用的能力
容器网络的出入网管控最常用的就是控制业务的对公网访问不同业务直接的网络资源隔离随着集群规模的变大不可避免的会存在多租户的场景不同租户之间的网络隔离 network policy 可以做到云原生领域的安全演练能力例如模拟某些网络异常可以直接通过NetworkPolicy 功能实现
二、Network Policy 和容器网络关系
云原生领域经过多年的发展上层的应用各种服务层出不穷作为云原生底层的基础服务容器网络也面临更多安全和网络管控的需求。比如在大规模集群中不同业务希望互相禁止访问一些内部服务希望禁止公网访问或被公网访问。kubernetes 对应这些类似需求给出的解决方案就是 Network Policy 。Network Policy 的实现依赖于容器网络但是因为不同的 CNI 技术方案和组网方式的不同Network Policy 实现方式也是不同的所以 kubernetes 官方只给出了一个 Network Policy 的格式规范并没有给出具体的实现方案示例如下
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 原生的Network Policy
kubernetes 原生的 Network Policy 功能相对简单只支持 namespace 级别功能且相对简单支持 L3 和 L4 基础的网络策略。
3.1 匹配规则
Ingress 顾名思义外部流量流入 Pod
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
Ingress 通过 From 关键字来配置规则可以通过ipBlock、namespaceSelector、podSelector、Ports 来选择该策略所使用的对象。
podSelector此选择器将在与 NetworkPolicy 相同的 namespace 中选择特定的 Pod应将其允许作为入站流量来源或出站流量目的地。
namespaceSelector此选择器将选择特定的 namespace应将所有 Pod 用作其入站流量来源或出站流量目的地。
namespaceSelector 和 podSelector一个指定 namespaceSelector 和 podSelector 的 to/from 条目选择特定 namespace 中的特定 Pod。
Egress Pod 的出向流量
Egress 匹配策略和 ingress 基本一致只是from 字段改为to
3.2 官方案例
默认拒绝所有的入站流量在 default namespace 下生效
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
四、开源组件拓展Network Policy
kubernetes 提供的原生的Network Policy 所能实现的功能相对较少很难满足日益复杂的容器网络管控需求所以各家CNI 基本上都有自己标准的Network Policy
4.1 Calico Network Policy
Calico 的Network Policy 相较于Kubernetes 原生的Network Policy 有两点需要特别注意第一个是增加了集群级别的网络策略第二个是对于流量的处理处理正常的allow 和 deny 还多了一个log 用来记录被network policy 匹配到的流量 注这里只介绍Calico 开源版本企业版本的calico 不在本文的介绍范围内。
集群级别的网络策略 相较于k8s 原生的namespace 级别的网络策略集群级别网络策略是一种非namespace 资源可以应用于独立于命名空间的任何类型的端点pod、VM、主机接口。
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:name: allow-tcp-port-6379标准的Calico Network Policy 在以下示例中传入到应用程序的 TCP 流量被拒绝并且每个连接尝试都记录到系统日志中
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:name: allow-tcp-6379namespace: production
spec:selector: role databasetypes:- Ingress- Egressingress:- action: Logprotocol: TCPsource:selector: role frontend- action: Denyprotocol: TCPsource:selector: role frontend4.2 Cilium Network Policy
Cilium CNI 提供的Network Policy 的功能相对较多它不仅支持3层、四层、7层同时还支持通过自定义实体身份来选择Network Policy 生效位置
4.2.1 三层Network Policy
****Cilium 的 Network Policy 支持多种模式这里只选两个经典的来介绍
4.2.1.1 基于 ipBlock
此示例显示所有含 appmyservice 的 Pod 访问 20.1.1.1/32 和除了 10.96.0.0/12 所有 10.0.0.0/8 范围的地址
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: cidr-rule
spec:endpointSelector:matchLabels:app: myServiceegress:- toCIDR:- 20.1.1.1/32- toCIDRSet:- cidr: 10.0.0.0/8except:- 10.96.0.0/12
4.2.1.2 基于 DNS 下面的示例表示允许 default namespace 下标签为 apptest-app 的 pod 向 kube-system namespace 下标签为 k8s:k8s-appkube-dns 的 pod 的 53 端口发送请求”my-remote-service.com“的域名解析请求
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: to-fqdn
spec:endpointSelector:matchLabels:app: test-appegress:- toEndpoints:- matchLabels:k8s:io.kubernetes.pod.namespace: kube-systemk8s:k8s-app: kube-dnstoPorts:- ports:- port: 53protocol: ANYrules:dns:- matchPattern: *- toFQDNs:- matchName: my-remote-service.com
4.2.2 四层的Cilium Network Policy
四层的网络策略和 K8S 原生的规范除个别字段名称之外基本一致所以只给出一个基本的例子 以下规则限制所有具有appmyService标签的 pod 只能使用端口 80-444 上的 TCP 向任何第 3 层目的地发送数据包
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: l4-port-range-rule
spec:endpointSelector:matchLabels:app: myServiceegress:- toPorts:- ports:- port: 80endPort: 444protocol: TCP
4.2.3 七层的Cilium Network Policy
7层的Network Policy 目前支持的有 HTTP 协议Kafka 相关以及DNS相关
// L7Rules is a union of port level rule types. Mixing of different port
// level rule types is disallowed, so exactly one of the following must be set.
// If none are specified, then no additional port level rules are applied.
type L7Rules struct {// HTTP specific rules.//// optionalHTTP []PortRuleHTTP json:http,omitempty// Kafka-specific rules.//// optionalKafka []PortRuleKafka json:kafka,omitempty// DNS-specific rules.//// optionalDNS []PortRuleDNS json:dns,omitempty
}
4.2.3.1 HTTP 相关的L7 Network Policy
http 相关的NetworkPolicy 可以匹配path、method、host、headers 等信息使用起来非常灵活
基于 url path
下面的例子允许从带有“envprod”标签的 Pod 到带有“appservice”标签的 Pod 的 GET 请求访问 URL /public但对其他任何 URL 或使用其他方法的请求将被拒绝。除端口 80 以外的其他端口上的请求将被丢 apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: rule1
spec:description: Allow HTTP GET /public from envprod to appserviceendpointSelector:matchLabels:app: serviceingress:- fromEndpoints:- matchLabels:env: prodtoPorts:- ports:- port: 80protocol: TCPrules:http:- method: GETpath: /public
基于 path method header
下面的例子限制了所有带有标签“appmyService”的 Pod 只能通过 TCP 协议接收端口 80 上的数据包。在使用这个端口进行通信时仅允许以下两个 API GET /path1 和 PUT /path2并且必须在 HTTP 头“X-My-Header”中设置值为 true。
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: l7-rule
spec:endpointSelector:matchLabels:app: myServiceingress:- toPorts:- ports:- port: 80protocol: TCPrules:http:- method: GETpath: /path1$- method: PUTpath: /path2$headers:- X-My-Header: true
4.2.3.2 KafKa相关的L7 Network Policy(beta) • 允许使用“produce” role 创建 topic
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: rule1
spec:description: enable empire-hq to produce to empire-announce and deathstar-plansendpointSelector:matchLabels:app: kafkaingress:- fromEndpoints:- matchLabels:app: empire-hqtoPorts:- ports:- port: 9092protocol: TCPrules:kafka:- role: producetopic: deathstar-plans- role: producetopic: empire-announce
• 允许使用 apiKeys 生成 topic
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: rule1
spec:description: enable empire-hq to produce to empire-announce and deathstar-plansendpointSelector:matchLabels:app: kafkaingress:- fromEndpoints:- matchLabels:app: empire-hqtoPorts:- ports:- port: 9092protocol: TCPrules:kafka:- apiKey: apiversions- apiKey: metadata- apiKey: producetopic: deathstar-plans- apiKey: producetopic: empire-announce
4.2.3.3 DNS 相关的L7 Network Policy
下面的示例表示允许 default namespace 下标签为 orgalliance 的 pod 向 kube-system namespace 下标签为 k8s:k8s-appkube-dns 的 pod 的 53 端口发送请求”my-remote-service.com“的域名解析请求允许的域名为 cilium.io *. cilium.io .api.cilium.io 同时允许 cilium.io sub.cilium.io service1.api.cilium.io specialservice.api.cilium.io 的外部请求
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: tofqdn-dns-visibility
spec:endpointSelector:matchLabels:any:org: allianceegress:- toEndpoints:- matchLabels:k8s:io.kubernetes.pod.namespace: kube-systemk8s:k8s-app: kube-dnstoPorts:- ports:- port: 53protocol: ANYrules:dns:- matchName: cilium.io- matchPattern: *.cilium.io- matchPattern: *.api.cilium.io- toFQDNs:- matchName: cilium.io- matchName: sub.cilium.io- matchName: service1.api.cilium.io- matchPattern: special*service.api.cilium.iotoPorts:- ports:- port: 80protocol: TCP
4.2.4 集群联邦(Cluster Federation)的Cilium Network Policy
kubernetes 在 1.8 版本起就声称单个集群最多可支持 5000 个 node 和 15 万个 Pod但是实际上我们关注近几年互联网上因为服务崩溃而上的几次热搜就应该明白大规模集群一旦底层组件出现异常带来的影响是非常大的。这个时候我们就需要用到集群联邦Cluster Federation。有了集群联邦同样就需要考虑联邦级别的 Network Policy 恰巧 Cilium 就提供了对应的这一能力。 以下策略说明如何允许特定 pod 在两个集群之间进行通信。
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: allow-cross-cluster
spec:description: Allow x-wing in cluster1 to contact rebel-base in cluster2endpointSelector:matchLabels:name: x-wingio.cilium.k8s.policy.cluster: cluster1egress:- toEndpoints:- matchLabels:name: rebel-baseio.cilium.k8s.policy.cluster: cluster2
