Kubernetes1.7两大新特性| 日志审计变化& PodDisruptionBudget控制器变化

 ■ 文/ 天云软件 产品总监 马俊 

日志审计变化

背景概念

出于安全方面的考虑,Kubernetes提供了日志审计记录,用来记录不同普通用户、管理员和系统中各个组件的日志信息。

Kubernetes日志审计是Kube-apiserver组件的一部分功能,通过日志审计来记录apiserver上面所有请求处理过程。每条审计日志记录包括两行:

1、请求行:唯一ID、源IP、请求用户、请求资源信息、模拟信息等。

2、响应行:唯一ID、相应信息代码。

通过唯一ID就可以识别出对应的请求行和响应行。

下面的例子就是admin用户查询default命名空间中POD信息的两行审计日志信息。

2017-03-21T03:57:09.106841886-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" ip="127.0.0.1" method="GET" user="admin" groups="\"system:masters\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods" 
2017-03-21T03:57:09.108403639-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" response="200"
1.7新特性

我们先来看看1.7版本中日志审计相关的几个核心结构体:

日志

在Kubernetes 1.7中,新增加了两个结构体,分别是AuditOptions和AuditWebhookOptions。在AuditOptions结构体中通过LogOptions参数来对应之前版本的AuditLogOptions结构体。

一、AuditLogOptions结构体介绍

1、Path参数:如果设置了这个参数,那么所有访问apiserver的请求都会被记录到这个参数指向的文件,也可以设置成“-”,这样表示请求输出到标准输出中。

2、MaxAge参数:保存日志审计记录的最大天数,超出保存最大天数的日志审计记录都会被删除掉。

3、MaxBackups参数:保存日志审计记录文件的最大个数,超出保存最大个数的日志审计记录都会被删掉。

4、MaxSize参数:一个日志审计记录文件的最大空间,单位是M。

二、 AuditWebhookOptions结构体介绍

1、ConfigFile参数:将Kubernetes日志审计结果向外部输出的配置文件。

2、Mode参数:将Kubernetes日志审计结果向外部输出模式。在1.7版本中有两种输出模式,batch模式,表示缓存日志审计记录,然后批量发送给外部接收端;blocking模式,表示每条发送给外部接收端,发送的时候apiserver处在阻塞状态。

三、AuditOptions结构体介绍

1、PolicyFile参数:日志审计策略配置文件,通过这个文件可以配置哪些信息会生成日志审计记录。

2、LogOptions参数:表示AuditLogOptions结构体。

3、WebhookOptions参数:表示AuditWebhookOptions结构体。

在Kubernetes1.7中如果想启用日志审计新的功能,那么需要在启动kube-apiserver组件时,增加一个新的参数: –feature-gates=AdvancedAuditing=true。

一旦启用了AdvancedAuditing参数,那么Kubernetes在日志审计中就可以配置审计策略和审计处理方式。日志审计策略配置文件中可以配置不同审计级别策略,包括:

1、None:与此规则匹配的日志审计事件不用被记录。
2、Metadata:记录请求的元数据信息,包括用户、时间戳、请求类型等信息。
3、Request:记录请求的元数据和请求内容信息。
4、RequestResponse:记录请求的元数据、请求内容信息、响应内容信息。

另外一旦启用了这个参数,日志审计也不会按照之前每条审计日志记录两行信息了。日志审计记录在不同的阶段会记录不同的信息,其中包括:

1、RequestReceived阶段:在这个阶段,审计处理程序收到请求后立即生成日志审计事件。

2、ResponseStarted阶段:在这个阶段,响应标头被发送出去了,但是响应内容还没有被发送,此日志审计记录在长时间运行的响应时会生成。

3、ResponseComplete阶段:在这个阶段,一旦响应内容被发送出去了,那么就会生成日志审计记录。

4、Panic阶段:当有错误发生时,会生成日志审计记录。

新特性例子

1、下面的例子是日志审计策略配置文件的配置信息,表示按照Metadata级别记录所有请求信息。

rules:
- level: Metadata

2、下面的例子是日志审计策略配置文件的配置信息,表示不对用户system:kube-proxy在endpoints和services两种类型资源上的信息进行审计。

rules:
   - level: None
   users: ["system:kube-proxy"]
   verbs: ["watch"] 
   resources:
   - group: "" # core API group
   resources: ["endpoints", "services"]

3、下面的例子是日志审计策略配置文件的配置信息,表示审计表空间kube-system中configmaps资源类型的请求。

rules:
  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
    - group: "" # core API group
      resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"]

4、下面的例子是设置审计处理方式。

--audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
--audit-webhook-mode=batch

使用batch模式,向/etc/kubernetes/audit-webhook-kubeconfig文件中配置的服务端发送日志审计信息。

PodDisruptionBudget控制器变化

背景概念

在Kubernetes中,为了保证业务不中断或业务SLA不降级,需要将应用进行集群化部署。通过PodDisruptionBudget控制器可以设置应用POD集群处于运行状态最低个数,也可以设置应用POD集群处于运行状态的最低百分比,这样可以保证在主动销毁应用POD的时候,不会一次性销毁太多的应用POD,从而保证业务不中断或业务SLA不降级。

在Kubernetes 1.5中,kubectl drain命令已经支持了PodDisruptionBudget控制器,在进行kubectl drain操作时会根据PodDisruptionBudget控制器判断应用POD集群数量,进而保证在业务不中断或业务SLA不降级的情况下进行应用POD销毁。

1.7新特性

我们先来看看1.7版本中Pod Disruption相关的几个核心结构体:

POD

在Kubernetes 1.7中,在PodDisruptionBudgetSpec结构体中新增加了一个参数MaxUnavailable,通过这个参数可以设置最大不可用POD数,这是一个β特性。

可以看到,从版本1.7开始可以通过两个参数来配置PodDisruptionBudget:

1、MinAvailable参数:表示最小可用POD数,应用POD集群处于运行状态的最小POD数量,或者是运行状态的POD数同总POD数的最小百分比。

2、MaxUnavailable参数:表示最大不可用POD数,应用POD集群处于不可用状态的最大POD数,或者是不可用状态的POD数同总POD数的最大百分比。

这里需要注意的是,MinAvailable参数和MaxUnavailable参数是互斥的,也就是说如果使用了其中一个参数,那么就不能使用另外一个参数了。

比如当进行kubectl drain或者POD主动逃离的时候,Kubernetes可以通过下面几种情况来判断是否允许:

1、minAvailable设置成了数值5:应用POD集群中最少要有5个健康可用的POD,那么就可以进行操作。

2、minAvailable设置成了百分数30%:应用POD集群中最少要有30%的健康可用POD,那么就可以进行操作。

3、maxUnavailable设置成了数值5:应用POD集群中最多只能有5个不可用POD,才能进行操作。

4、maxUnavailable设置成了百分数30%:应用POD集群中最多只能有30%个不可用POD,才能进行操作。

在极端的情况下,比如将maxUnavailable设置成0,或者设置成100%,那么就表示不能进行kubectl drain操作。同理将minAvailable设置成100%,或者设置成应用POD集群最大副本数,也表示不能进行kubectl drain操作。

这里需要注意的是,使用PodDisruptionBudget控制器并不能保证任何情况下都对业务POD集群进行约束,PodDisruptionBudget控制器只能保证POD主动逃离的情况下业务不中断或者业务SLA不降级,例如在执行kubectl drain命令时。

新特性例子

1、下面的例子使用了minAvailable参数。

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:  
  name: zk-pdb
spec:  
  minAvailable: 2 
  selector:  
    matchLabels:    
      app: zookeeper

2、下面的例子使用了maxUnavailable参数。

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata: 
 name: zk-pdb
spec: 
  maxUnavailable: 1 
  selector:   
    matchLabels:   
      app: zookeeper

当zk-pdb对象副本数是3的时候,上面这两个例子所表达的意思是一样的。

3、可以通过下面命令创建PodDisruptionBudget对象。

kubectl create -f mypdb.yaml.

对于PodDisruptionBudget对象,无法直接进行更新操作,只能通过删除和重新创建来完成对PodDisruptionBudget对象的更新。

4、可以通过下面命令查看PodDisruptionBudget对象的状态。

$ kubectl get poddisruptionbudgets
NAME      MIN-AVAILABLE   ALLOWED-DISRUPTIONS   AGE
zk-pdb    2               1                     7s

5、可以通过下面命令查看PodDisruptionBudget对象的详细信息。

$ kubectl get poddisruptionbudgets zk-pdb -o yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata: 
 name: zk-pdb
...
status: 
  currentHealthy: 3
  desiredHealthy: 3
  disruptedPods: null
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1

—END—