Fluent Bit 和 Fluentd 一樣，是 Treasure Data 資助的採集工具，二者對比如下：

從上表可以看出，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 資訊的授權，要成功執行，就必須按照

首先為 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.6/1.7 叢集上運行了。開啟相應的 Kibana 頁面，會看到和標配 Fluentd 一致的日誌蒐集結果。