log | 伪架构师

Kubernetes 的审计日志和采集

Thu, 31 Aug 2017 01:35:22 +0800

基础操作

一个正常运行的 Kubernetes 集群，除了利用访问控制对集群操作的许可进行限制之外，对于操作过程的跟踪审计也是比不可少的，围绕不同的实体，例如用户、节点以及各种工作负载进行观测是很有必要的。Kubernetes 的 API Server 提供了审计日志支持，利用审计日志的方式对系统内的操作进行记录，这里我们可以沿用推荐的 Elastic Search + Fluentd 对审计日志进行采集存储，最终使用 Kibana 或者其他支持 ES 查询的工具对关键资源或用户进行访问跟踪。

首先要启用 API Server 的审计功能。Kubernetes 提供了四个基础参数来定义审计功能：

audit-log-path 启用审计日志，并将日志内容写入指定文件，“-” 代表 stdout。
audit-log-maxage 日志文件的最大保存天数，根据文件名中的日期进行确定。
audit-log-maxbackup 最多保存日志文件的数量。
audit-log-maxsize 最大文件尺寸，超过尺寸会被翻转。单位是 MB，缺省为 100MB。

例如：

--audit-log-path=/var/log/kubernetes/kubernetes.audit \
--audit-log-maxage=7 \
--audit-log-maxbackup=4 \
--audit-log-maxsize=10

在 Kubernetes API Server 的启动参数中加入这些开关之后，重新启动服务。

这时我们就可以看到文件/var/log/kubernetes/kubernetes.audit已经生成。利用 tail 命令看看他的结构和内容，例如请求内容是这样的：

2017-08-30T16:28:35.485818099+08:00 AUDIT: id="ebc47b7b-c4fe-4a9a-861c-d9686903cec4" ip="127.0.0.1" method="GET" user="system:apiserver" groups="\"system:masters\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/apis/admissionregistration.k8s.io/v1alpha1/initializerconfigurations"

而响应内容格式如下：

2017-08-30T16:28:35.486131325+08:00 AUDIT: id="ebc47b7b-c4fe-4a9a-861c-d9686903cec4" response="404"

我们本文中暂时只对请求内容进行进一步解析，响应内容可以通过加入第二格式的方式进行采集。内容中的id字段，可以看作是会话 id，用于连接请求和响应。

根据上述文本内容，可以开始 Fluentd 文件的编写。请求和响应的内容都很规则，简单的正则表达式即可完成解析，例如我写的是这样的：

<source>
  type tail
  format /^(?<time>\d.*?)\s+(?<action>\w+).\s+id=\"(?<id>.*?)\"\s+ip=\"(?<ip>.*?)\"\s+method=\"(?<method>.*?)\"\s+user=\"(?<user>.*?)\"\s+groups=(?<groups>.*?)\s+as=\"(?<as>.*?)\"\s+asgroups=\"(?<asgroups>.*?)\"\s+namespace=\"(?<namespace>.*?)\"\s+uri=\"(?<uri>.*?)\"$/
  path /var/log/kubernetes/kubernetes.audit
  pos_file /var/log/audit.pos
  time_format %Y-%m-%dT%H:%M:%S.%N%z
  tag audit.response
</source>

将这一部分内容加入到 Fluentd 配置之中去，启动抓取。日志入库之后，我们就可以对指定用户或者资源进行查询，获知他的黑历史了，例如我们要查找用户admin的操作历史：

{
  "query": {
    "match": {
      "user": {
        "query": "admin",
        "type": "phrase"
      }
    }
  }
}

在 Kibana 中执行查询，会看到类似内容（如果所在集群没有该用户，可以替换为 system:apiserver等内置用户进行测试）：

利用解析出的各个字段，可以比较清楚的看到什么人，在什么时间，对什么对象进行了什么操作。

高级审计

在 Kubernetes 1.7 中新增了 Advanced audit 特性（Alpha），可以对审计内容、以及后续处理进行定义。

首先加入了审计策略的支持，可以使用行为，动作等条件进行限制，过滤掉无需考虑的审计内容。
存储后端在日志之外，还增加了 Web Hook 的支持，可以直接将审计内容发布到指定的 Web 服务中。

在 Kubernetes 中使用 Fluent Bit 进行日志采集

Mon, 10 Jul 2017 08:51:52 +0800

Fluent Bit 和 Fluentd 一样，是 Treasure Data 资助的采集工具，二者对比如下：

	Fluentd	FluentBit
范围	服务器	嵌入设备和 IoT 设备
内存	约 20 MB	约 150 KB
语言	C 和 Ruby	C
性能	高	高
依赖	以 Ruby Gem 构建，依赖一系列的 Gem	零依赖，可能有些插件会有依赖。
插件	超过三百个	目前15个左右
授权	Apache License v2.0	Apache License v2.0

从上表可以看出，Fluentd 具有众多插件，随之而来的是很好的弹性。而 Fluent Bit 则更适用于嵌入设备等资源受限的场景。另外二者并非互斥关系，Fluent Bit 提供了输出插件，可以把数据发给 Fluentd，因此他们可以在系统中作为独立服务互相协作。

Fluent Bit 也提供了 Kubernetes Filter 插件，用于将采集到的日志结合对 Kubernetes API 的查询，为日志加入 Kubernetes 的相关数据，例如 Pod 信息、容器信息、命名空间以及标签和注解等内容。

仅就此来说，Fluent Bit 是可以替代 Kubernetes 缺省推荐的 Fluentd 进行日志采集工作的，经过笔者测试，可以直接使用他替代原有的 Fluentd，使用 DaemonSet 运行，结合 Elastic Search 进行日志归集工作。

详情参见：http://fluentbit.io/documentation/0.11/filter/kubernetes.html

简单的使用如下命令就可以运行：

    kubectl create -f https://raw.githubusercontent.com/fluent/fluent-bit-kubernetes-daemonset/master/fluent-bit-daemonset-elasticsearch.yaml

这一 YAML 文件中的镜像版本为 0.11，具体版本更新可以到 Docker Hub 进行查询，其中包含的缺省 elasticsearch 地址为 elasticsearch-logging，端口为 9200，如上配置如果不符，可以下载文件自行修改运行。

另外目前 RBAC 的访问控制模式已经成为缺省，在启用了 RBAC 模式的集群中，该 Pod 的运行是无法成功的，具体表现是日志中出现无法获取 Pod 元数据的信息，这是因为缺省情况下，这一 YAML 中使用的是 kube-system 中的 default Service Account，这一服务账号并不具备获取 Pod 信息的授权，要成功运行，就必须按照 RBAC 的规矩，让 Fluent Bit 的 Service Account 能够获取 Pod 信息，可以用如下方式来解决：

首先为 Fluent bit 创建专门的 Service Account：

    kubectl create sa logging -n kube-system

然后为日志收集器创建角色，让该角色可以读取 Pod 信息。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

接下来创建 ClusterRoleBinding，把新建的角色和 Service Account 绑定在一起：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods-global
subjects:
- kind: ServiceAccount
  name: logging
  namespace: kube-system
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

最后在 Fluent Bit 的 yaml 中加入 Service Account 的指派：

# 省略若干
spec:
  template:
    metadata:
      labels:
        k8s-app: fluent-bit-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccountName: logging
# 省略若干

经过这一番折腾之后，Fluent Bit 就可以在开启 RBAC 的 1.⁶⁄₁.7 集群上运行了。打开相应的 Kibana 页面，会看到和标配 Fluentd 一致的日志搜集结果。

好吧，今天讲的其实是 RBAC。

简单的 Kubernetes Pod 日志查看工具 Kubetail

Sat, 11 Mar 2017 01:47:52 +0800

传统来说，Kubernetes 环境下的日志都是靠 FluentD + ElasticSearch + Kibana 的组合实现的，这一组合的功能和强大，所以成为一个事实标准来使用，但是在一些比较简陋的测试集群中，或者不具备浏览器条件的自动化/控制台环境下，归并多个 Pod 的日志进行集中的查看和处理还是很有用的。

Kubetail 是一个 Bash 脚本，功能类似 kubectl -f logs pod-name，但是不同的是，他同时对多个 Pod 工作，并把日志合并到一个流中。

项目网址：github

安装

只是个脚本，可以直接下载安装。

Mac 用户：

brew tap johanhaleby/kubetail && brew install kubetail

使用

kubetail [-h] [-c] [-n] [-t] [-l] [-s] pod-name-prefix

-c：多容器 Pod 中，指定容器名称
-t：指定 kube config 文件中的 context
-l：标签过滤器，使用 -l 参数之后，会忽略后面的 pod 名称
-n：namespace
-s：只返回一个相对时间之后的日志，例如 5s，2m 或者 3h，缺省是 10s
-b：是否使用 line-buffered。缺省为 false
-k：输出的着色
pod：只给 pod 名称上色
line：整行上色（缺省）
false：不上色