专栏名称: HULK一线技术杂谈
HULK是360的私有云平台,丰富的一线实战经验,为你带来最有料的技术分享
目录
相关文章推荐
51好读  ›  专栏  ›  HULK一线技术杂谈

Kubernetes NetworkPolicy 工作原理浅析

HULK一线技术杂谈  · 公众号  ·  · 2018-03-08 18:00

正文


女主宣言

Kubernetes能够把集群中不同Node节点上的Pod连接起来,并且默认情况下,每个Pod之间是可以相互访问的。但在某些场景中,不同的Pod不应该互通,这个时候就需要进行访问控制。那么如何实现呢?本文最先发布于 opsdev,转载已获取作者授权。

PS:丰富的一线技术、多元化的表现形式,尽在“ HULK一线技术杂谈 ”,点关注哦!

简介

Kubernetes提供了NetworkPolicy的Feature,支持按Namespace和按Pod级别的网络访问控制。它利用label指定namespaces或pod,底层用iptables实现。这篇文章简单介绍Kubernetes NetworkPolicy在Calico上的工作原理。

1

控制面数据流

Network Policy是一种kubernetes资源,经过定义、存储、配置等流程使其生效。以下是简要流程:

  • 通过kubectl client创建network policy资源;

  • calico的policy-controller监听network policy资源,获取到后写入calico的etcd数据库;

  • node上calico-felix从etcd数据库中获取policy资源,调用iptables做相应配置。


2

资源配置模板

Network Policy支持按Pod和Namespace级别的访问控制,定义该资源可以参考以下模板。

指定pod标签访问

我们要对namespace为myns,带有"role: backend"标签的所有pod进行访问控制:只允许标签为"role: frontend"的Pod,并且TCP端口为6379的数据流入,其他流量都不允许。

指定namespaces标签访问

我们要对标签为"role: frontend"的所有Pod进行访问控制:只允许namespace标签为"user: bob"的各Pod,并且TCP端口为443的数据流入,其他流量都不允许。


3

NetworkPolicy数据结构定义

看完上边的示例,想必大家对NetworkPolicy的资源对象有一定的了解。接下来我们具体看下Kubernetes对该接口的定义:

简而言之,该资源指定了“被控制访问Pod”和“准入Pod”两类Pod,这可以从spec的podSelector和ingress-from的Selector进行配置。


接下来我们就看下Kubernetes+Calico的Network policy实现细节。


4

测试版本

以下是测试中使用的组件版本:


  • kubernetes:

- master: v1.9.0

- node: v1.9.0

  • calico:

- v2.5.0

- calico-policy-controller

( quay.io/calico/kube-policy-controller:v0.7.0 )


5

运行配置

calico侧,除基本配置外的新建资源:

  • service-account: calico-policy-controller

  • rbac:

- ServiceRole: calico-policy-controller

- ServiceRoleBinding: calico-policy-controller

  • deployment: calico-policy-controller


Kubernets侧,新建network policy资源;


6

运行状态

在原有正常工作的Kubernetes集群上,我们新加了calico-policy-controller容器,它里面主要运行controller进程:


  • calico-policy-controller:

- 进程

- 端口:

我们可以看到,启动了controller进程,该进程Established两个端口:6443对应的kubernetes api-server端口;2379对应的calico etcd端口。

7

Calico-felix对policy的配置

数据包走向

下图是calico流量处理流程(从这里找到)。每个Node的calico-felix从etcd数据库拿下来policy信息,用iptables做底层实现,最主要的就是: cali-pi-[POLICY]@filter 这个Chain。


Network Policy报文处理过程中使用的标记位:

0x2000000: 是否已经经过了policy规则检测,置1表示已经过

符号解释:

from-XXX: XXX发出的报文; tw: 简写,to wordkoad endpoint; to-XXX: 发送到XXX的报文; po: 简写,policy outbound; cali-: 前缀,calico的规则链; pi: 简写,policy inbound; wl: 简写,workload endpoint; pro: 简写,profile outbound; fw: 简写,from workload endpoint; pri: 简写,profile inbound。

下面通过访问“禁止所有流量”策略的Pod,来观察对应的iptables处理:

流量进入前

流量进入后

可以看到,DROP的pkts由0变成了3。即该数据包经过MARK、cali-pi-default.web-deny-all两个target处理,被标记符合“拒绝”条件,流经到DROP被丢弃。


8

流程分析案例

以下是一个“禁止所有流量进入”的测试案例,通过它看下整体流程。

模型

DENY all traffic to an application

查看app-web的标签

在default的namespace下创建了一个名称为web的service。它的IP和标签如下:

配置policy

首先通过kubectl查看k8s资源:







请到「今天看啥」查看全文