Kubernetes之NetworkPolicy,Flannel和Calico

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kubernetes之NetworkPolicy,Flannel和Calico相关的知识,希望对你有一定的参考价值。

参考技术A

Pod是Kubernetes调度的最小单元。一个Pod可以包含一个或多个容器,因此它可以被看作是内部容器的逻辑宿主机。Pod的设计理念是为了支持多个容器在一个Pod中共享网络和文件系统。那么为什么Pod内的容器能够共享网络,IPC和PID命名空间?

原因:Kubernetes在每个Pod启动时,会自动创建一个镜像为gcr.io/google_containers/pause:version的容器,所有处于该Pod中的容器在启动时都会添加诸如--net=container:pause --ipc=contianer:pause --pid=container:pause的启动参数,因此Pod内所有容器共用pause容器的network,IPC和PID命名空间。所有容器共享pause容器的IP地址,也被称为Pod IP。因此处于同一个Pod内的容器,可以通过localhost进行相互访问。

在讲K8s Pod间通信前,我们先复习一下Docker容器间的网络通信。默认情况下,Docker使用一种名为bridge的网络模型。如下图所示:

Docker引擎在启动时,会在宿主机上创建一个名为docker0的虚拟网桥,这个虚拟网桥负责给所有容器分配不重复的ip地址以及容器间的网络通信。首先,Docker在创建一个容器时,会执行以下操作:

通过这个docker0网桥,同一宿主机上的容器可以互相通信。然而由于宿主机的IP地址与容器veth pair的 IP地址均不在同一个网段,故仅仅依靠veth pair和namespace的技术,还不足以使宿主机以外的网络主动发现容器的存在。为了使外界可以访问容器中的进程,docker采用了端口绑定的方式,也就是通过iptables的NAT,将宿主机上的端口端口流量转发到容器内的端口上。

K8s 默认不提供网络功能,所有Pod的网络功能,都依赖于宿主机上的Docker。因此,Pod IP即是依靠docker0网桥分配给pause容器的虚拟IP。

同一个Node内,不同的Pod都有一个docker0网桥分配的IP,可以直接通过这个IP进行通信。Pod IP和docker0在同一个网段。因此,当同节点上的Pod-A发包给Pod-B时,包传送路线如下:

不同的Node之间,Node的IP相当于外网IP,可以直接访问,而Node内的docker0和Pod的IP则是内网IP,无法直接跨Node访问。因此,不同Node上的Pod间需要通信,需要满足以下两个条件:

因此,为了实现以上两个需求,K8s提供了CNI(Container Network Interface)供第三方实现从而进行网络管理。由此出现了一系列开源的Kubernetes中的网络插件与方案,包括:flannel,calico,cilium等等。这些网络插件集中解决了以下需求:

CNI的介绍请参考这篇文章: https://jimmysong.io/kubernetes-handbook/concepts/cni.html

在默认的Docker配置中,每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是,不同节点上容器可能获得相同的内外IP地址。

Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则,从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址,并让属于不同节点上的容器能够直接通过内网IP通信。

Flannel实质上是一种“覆盖网络(overlay network)”,也就是将TCP数据包装在另一种网络包里面进行路由转发和通信,目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式,默认的节点间数据通信方式是UDP转发。下图展示了数据包在flannel中的流转:

Flannel是一种典型的Overlay网络,它将已有的物理网络(Underlay网络)作为基础,在其上建立叠加的逻辑网络,实现网络资源的虚拟化。Overlay网络有一定额外的封包和解包等网络开销,对网络通信的性能有一定损耗。

Calico是纯三层的SDN 实现,它基于BPG 协议和Linux自身的路由转发机制,不依赖特殊硬件,容器通信也不依赖iptables NAT或Tunnel 等技术。能够方便的部署在物理服务器、虚拟机(如 OpenStack)或者容器环境下。同时calico自带的基于iptables的ACL管理组件非常灵活,能够满足比较复杂的安全隔离需求。

Calico 还基于 iptables 还提供了丰富而灵活的网络 policy, 保证通过各个节点上的 ACLs 来提供 workload 的多租户隔离、安全组以及其他可达性限制等功能。

核心问题是,nodeA怎样得知下一跳的地址?答案是node之间通过BGP协议交换路由信息。

每个node上运行一个软路由软件bird,并且被设置成BGP Speaker,与其它node通过BGP协议交换路由信息。

可以简单理解为,每一个node都会向其它node通知这样的信息:

我是X.X.X.X,某个IP或者网段在我这里,它们的下一跳地址是我。

通过这种方式每个node知晓了每个workload-endpoint的下一跳地址。

K8s NetworkPoclicy 用于实现Pod间的网络隔离。在使用Network Policy前,必须先安装支持K8s NetworkPoclicy的网络插件,包括:Calico,Romana,Weave Net,Trireme,OpenContrail等。

在未使用NetworkPolicy前,K8s中所有的Pod并不存在网络隔离,他们能够接收任何网络流量。一旦使用NetworkPolicy选中某个namespace下的某些Pod,那么这些Pod只能接收特定来源的流量(由Ingress属性定义),并且只能向特定出口发送网络请求(由Egress属性定义)。其他未被这个NetworkPolicy选中的Pod,依然不具备网络隔离。

下面是一个NetworkPolicy的例子:

下面的例子表示默认禁止所有Pod间的Ingress流量:

默认拒绝所有 Pod 之间 Egress 通信的策略为:

而默认允许所有 Pod 之间 Ingress 通信的策略为:

默认允许所有 Pod 之间 Egress 通信的策略为:

以 calico 为例看一下 Network Policy 的具体用法。首先配置 kubelet 使用 CNI 网络插件:

安装 calio 网络插件:

首先部署一个 nginx 服务,此时,通过其他 Pod 是可以访问 nginx 服务的:

开启 default namespace 的 DefaultDeny Network Policy 后,其他 Pod(包括 namespace 外部)不能访问 nginx 了:

最后再创建一个运行带有 access=true label的 Pod 访问的网络策略:

Kubernetes_CNI_Calico_04_Calico的网络策略NetworkPolicy

系列文章目录

文章目录


前言

Kubernetes中和网络相关的组件包括三个:calico(flannel)、kube-proxy、coredns(之前是kubedns).

Kubernetes最常用的CNI组件只有两个,一个是Flannel,一个是Calico。其中,Flannel是没有网络策略的,只有Calico才有网络策略。


一、k8s 网络策略 NetworkPolicy

如果你希望在 IP 地址或端口层面(OSI 第 3 层或第 4 层)控制网络流量, 则你可以考虑为集群中特定应用使用 Kubernetes 网络策略(NetworkPolicy)。 NetworkPolicy 是一种以应用为中心的结构,允许你设置如何允许 Pod 与网络上的各类网络“实体” 通信。官方文档

网络策略是通过网络插件来实现,常用的网络插件Flannel和Calico:

  • Flannel:只能提供网络通讯,不提供网络策略,如果需要使用网络策略,建议使用下面的Calico,关于Flannel更详细的介绍和安装可以参考我这篇文章:Kubernetes(k8s)CNI(flannel)网络模型原理。
  • Calico:支持丰富的网络策略,Calico以其性能、灵活性而闻名。后面也会出相关文章详细介绍Calico。

更多了解更多的网络策略,可以参考官方文档:https://kubernetes.io/docs/concepts/cluster-administration/addons/

Pod 可以通信的 Pod 是通过如下三个标识符的组合来辩识的:

其他被允许的 Pods(例外:Pod 无法阻塞对自身的访问)
被允许的名字空间
IP 组块(例外:与 Pod 运行所在的节点的通信总是被允许的, 无论 Pod 或节点的 IP 地址)

二、Pod 隔离的两种类型

Pod 有两种隔离: 出口的隔离和入口的隔离。默认情况下,出口和入口都是非隔离的。

网络策略是相加的,所以不会产生冲突。如果策略适用于 Pod 某一特定方向的流量, Pod 在对应方向所允许的连接是适用的网络策略所允许的集合。 因此,评估的顺序不影响策略的结果。

要允许从源 Pod 到目的 Pod 的连接,源 Pod 的出口策略和目的 Pod 的入口策略都需要允许连接。 如果任何一方不允许连接,建立连接将会失败。

三、NetworkPolicy 资源

1)NetworkPolicy 示例演示

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

必需字段:与所有其他的 Kubernetes 配置一样,NetworkPolicy 需要 apiVersion、 kind 和 metadata 字段。关于配置文件操作的一般信息, 请参考配置 Pod 以使用 ConfigMap 和对象管理。

  • 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)
  • (Egress 规则)允许 “default” 命名空间中任何带有标签 “role=db” 的 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。

2)选择器 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
  ...

这里只是把官网的摘了一部分,官网介绍的比较清楚,这里就不粘贴复制了,小伙伴可以参考官方文档:https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

总结

在k8s上网络策略是白名单机制,所谓白名单机制是指,只有明确定义的策略才会被允许放行,默认没有指定的规则就是拒绝的,即条件不匹配的都会被拒绝。

其次对于ingress或egress来说,对应的from或to都是用来指定访问端或被访问端的信息。

如果我们在对应的字段中没有定义namespaceSelector字段,默认ingress或egrss会匹配当前netpol所在名称空间,即在没有明确指定namespaceSelector字段时,对应的其他条件都是针对当前netpol所在名称空间。

多个条件组合使用,如果多个条件都在一个列表中,则表示多个条件间是与关系,即指定的条件需要同时满足对应策略才会放行。
如果多个条件不再同一个列表中,则多个条件之间是或关系,即满足其中一个条件都会被对应策略放行。

参考资料:https://liugp.blog.csdn.net/article/details/127839272

以上是关于Kubernetes之NetworkPolicy,Flannel和Calico的主要内容,如果未能解决你的问题,请参考以下文章

Kubernetes_CNI_Calico_04_Calico的网络策略NetworkPolicy

精品k8s(kubernetes)的网络策略详networkpolicy实例精讲

关于 Kubernetes中NetworkPolicy(网络策略)方面的一些笔记

深入理解Kubernetes网络策略

每天5分钟玩转Kubernetes | Network Policy

k8s学习-网络策略NetworkPolicy(概念模版创建删除等)