Kubernetes单机部署+EFK日志收集

Kubernetes+EFK日志收集

本章资源：
kibana-7.4.2.tar软件包，因为这个包太大没办法上传到平台来，所以需要自己搜索了
剩余资源请访问：https://download.csdn.net/download/weixin_54373617/18737970

技能目标：

• 掌握 Kubernetes 离线部署的方法

• 掌握 Kubernetes 集群下 EFK 模型架构与原理

• 会基于 Kubernetes 集群的 EFK 安装与配置

• 学会使用业务容器验证 EFK 日志收集

案例概述

案例前置知识点

1. 什么是 Kubernetes

Kubernetes 是 2014 年 Google 和 Redhat 发布的开源项目。因为有了容器之后，就需要有一种方式去帮助用户方便、快速、优雅地管理这些容器，而这也是 Kubernetes 项目的初衷。

经过近几年的快速发展，目前 Kubernetes 已经成为容器编排领域的一种标准。在Docker 技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，极大的提高了大规模容器集群管理的便捷性。

2. Kubernetes 逻辑架构图

Kubernetes 提供了基于容器技术的分布式架构方案，主要由六大部分组成，分别为 API Server、Scheduler、Controller-Manager、Kubelet、ETCD 和 Kubectl CLI，如下图所示。

K8s架构图

（1） API Server
API Server 是模块之间数据交互和通信的枢纽，提供了集群管理的 REST API 接口， 包括认证授权、数据校验以及集群状态变更。所有的请求均通过 API Server 查询或者修改数据，且 API Server 是唯一和 ETCD 数据库交互的组件。API 与 ETCD 的交互流程如下图所示。

（2） Scheduler
Scheduler 是 Kubernetes 集群的调度器组件，运行在 Master 节点，它的核心功能是监听 API Server 获取 Pod，并通过一系列的调度策略（预选和优选）指示 Pod 分配到最优的 Node 节点中。

（3） Controller-Manager
Controller-Manager 是 Kubernetes 集群的控制器，作为集群内部的管理控制中心，内置了大量的资源控制器，比如副本控制器（Replication Controller）、节点控制器（Node Controller）等。每个 Controller 通过 API Server 提供的接口实时监控整个集群中的每个资源对象的当前状态。当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。

（4） Kubelet
在 Kubernetes 集群中，每个 Node 节点都会启动 Kubelet 进程，用来处理 Master 节点下发到本节点的任务，管理 Pod 和其中的容器。Kubelet 会在 API Server 上注册节点信息， 定期向 Master 汇报节点资源使用情况，并通过 cAdvisor 监控容器和节点资源。可以把Kubelet 理解成 Server-Agent 架构中的 Agent，是 Node 节点上的 Pod 管家。

（5） ETCD
ETCD 是一款分布式的一致性 KV 存储，使用的是 Raft 一致性算法，主要用于共享配置和服务发现。
Kubernetes 集群使用 ETCD 来存储集群所有的网络配置和对象的状态信息。

（6） Kubectl CLI
Kubectl 是一个用于操作 Kubernetes 集群的命令行接口。利用 Kubectl 的各种命令可以操作 Kubernetes 集群的各类资源，是在使用 Kubernetes 过程中非常常用的工具。

3. Kubernetes 角色

Kubernetes 集群主要由两类角色组成。

（1） 管理节点
管理节点(Master Node)是用来部署集群的管理组件，主要包含 API Server、Scheduler、Controller-Manager 及 ETCD 数据库，是整个集群的中控大脑，负责控制集群中各类资源的状态，提供 API 等。

（2） 工作节点
工作节点(Worker Node)负责监听资源变化，并将 Pod 运行起来。

4. Kubernetes 集群 Pod 控制器

业务应用在 Kubernetes 集群中以 Pod 的资源形式存在。 Pod 控制器是用于实现管理Pod 的中间层，确保 Pod 资源符合预期的状态，当 Pod 的资源出现故障时，会尝试进行重启，如果重启策略无效，则会重新建立 Pod 的资源。常用的 Pod 控制器类型包含以下几种：

（1）ReplicaSet

ReplicaSet 可以根据用户需求创建指定的Pod 副本数量，确保 Pod 副本数量符合预期， 并且支持滚动式自动扩容和缩容功能。ReplicaSet 的定义包括如下三个组成部分：

• 用户期望的 Pod 副本数量。

• 标签选择器，判断哪个 Pod 归自己管理。

• 当现存的 Pod 数量不足，会根据 Pod 资源模板进行创建。帮助用户管理无状态的Pod 资源，精确反应用户定义的目标数量，但是 RelicaSet 不是直接使用的控制器， 而是使用 Deployment。

（2）Deployment

Deployment 工作在 ReplicaSet 之上，用于管理无状态应用，目前来说是最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。

本章使用 Deployment 来管理 kibana 服务。

（3） DaemonSet

DaemonSet 用于确保集群中的每一个节点只运行特定的 Pod 副本，通常用于实现系统级后台任务，比如 ELK 服务。它的特性是：服务是无状态的且服务必须是守护进程。

本章使用 DaemonSet 来管理 Fluentd 做日志采集。

（4） StatefulSet

StatefulSet 用于管理所有有状态的服务，比如 MySQL、MongoDB 等。

StatefulSet 本质上是 Deployment 的一种变体，在 v1.9 版本中已成为 GA 版本，为了解决有状态服务的问题，所管理的 Pod 拥有固定的 Pod 名称、启停顺序。在 StatefulSet 中，Pod 名称称为网络标识(hostname)，还必须要用到共享存储。

在Deployment 中，与之对应的服务是 service，而在 StatefulSet 中与之对应的headless service。headless service 即无头服务，与 service 的区别就是它没有 Cluster IP，解析它的名称时将返回该 Headless Service 对应的全部 Pod 的 Endpoint 列表。

本章使用 StatefulSet 管理 ES 服务。

5. Kubernetes 服务部署工作流程

通常使用 kubectl 工具来进行服务部署，具体的工作流程如下图所示。

Kubernetes 的服务部署流程如下所示：

第一步，用户通过 API Server 的 REST API 或 Kubectl 命令行工具提交创建 Pod 的请求，支持 Json 和 Yaml 两种格式；

第二步，API Server 处理用户请求，存储 Pod 数据到 etcd；

第三步，Scheduler 通过 API Server 的 watch 机制，查看到新的 Pod，尝试将 Pod 绑定到 Node 节点；

第四步，调度器用一组规则过滤掉不符合要求的主机，比如 Pod 指定了所需要的资源， 那么就要过滤掉资源不够的主机；

第五步，对上一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把一个 Replication Controller 的副本分布到不同的主机上，使用最低负载的主机等；

第六步，选择打分最高的主机，进行 Binding 操作，结果存储到 etcd 中；

第七步，Kubelet 根据调度结果执行 Pod 创建操作。当绑定成功后，会启动 container， docker run、scheduler 会调用 API 在数据库 etcd 中创建一个 Bound Pod 对象，用来描述在一个工作节点上绑定运行的所有 Pod 信息。运行在每个工作节点上的 Kubelet 也会定期与 etcd 同步 Bound Pod 信息，一旦发现应该在该工作节点上运行的 Bound Pod 对象没有更新，则调用 Docker API 创建并启动 Pod 内的容器。

6. 什么是 Elasticsearch

Elasticsearch 是一个 Restful 风格的、开源的分布式引擎，具备搜索和数据分析功能， 它的底层是开源库 Apache Lucene。Elasticsearch 具有如下特点。

• 一个分布式的实时文档存储，每个字段可以被索引与搜索；

• 一个分布式实时分析搜索引擎；

• 能支撑上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据。

7. Fluentd 工作原理

Fluentd 是一个日志的收集、处理、转发系统。通过丰富的插件，可以收集来自各种系统或应用的日志，转化为用户指定的格式后，转发到用户所指定的日志存储系统中。Fluentd 数据转发过程如下图所示。

Fluentd 通过一组给定的数据源抓取日志数据，处理后（转换成结构化的数据格式）将它们转发给其他服务，比如 Elasticsearch、对象存储等等。Fluentd 支持超过 300 个日志存储和分析服务，所以对日志存储和分析服务的支持是非常灵活的。Fluentd 采用了插件式的架构，具有高可扩展性及高可用性，同时还实现了高可靠的信息转发。其主要运行步骤如下所示：

（1） 首先 Fluentd 从多个日志源获取数据。

（2） 结构化并且标记这些数据。

（3） 最后根据匹配的标签将数据发送到多个目标服务。

8. 什么是 Kibana

Kibana 是一个开源的可视化分析平台，用于和 Elasticsearch 一起工作。可以通过Kibana 搜索、查看、交互存放在 Elasticsearch 索引中的数据。也可以轻松地执行高级数据分析，并且以各种图表、表格和地图的形式可视化数据。Kibana 简单的、基于浏览器的界面便于对大量数据进行呈现，能够快速创建和共享动态仪表板，实时显示 Elasticsearch 查询的变化。

案例概述

近年来，随着 Docker 容器及云原生相关技术的迅速发展，国内外厂商开始逐步向云原生方向转型。其中以 Kubernetes 为代表性的云原生技术凭借强大的功能成为各大厂商的第一选择。由于 Kubernetes 在容器编排领域的强势领先，使得越来越多的企业将业务迁至基于 Docker+Kubernetes 技术栈打造的容器管理平台，所以在 Kubernetes 集群环境下如何打造高效、可靠的业务日志收集系统也成为企业必须面临的问题。本章将主要介绍基于Elasticsearch、Fluentd 和 Kibana（EFK）技术栈实现完整 Kubernetes 集群日志收集解决方案。

案例环境

1. 本案例环境

本案例具体的实验环境如下表所示。其中，K8smaster 主机使用的 CPU 核心要求大于等于2内存也要大于等于2。同时，为保证 Elasticsearch 可以正常提供服务，运行 Elasticsearch 的节点要有足够的内存，通常来讲内存要不低于 4GB。若 Elasticsearch 容器退出，请检查宿主机中的/var/log/message 日志，观察是否因为系统 OOM 导致进程被杀掉。

主机名	IP地址	操作系统	配置	角色	部署组件
k8sinit	192.168.10.101	CentOS7.9	2C/2G	初始化节点
k8smaster1	192.168.10.102	CentOS7.9	2C/2G	管理节点
k8smaster2	192.168.10.103	CentOS7.9	2C/2G	管理节点
k8smaster3	192.168.10.104	CentOS7.9	2C/2G	管理节点
k8snode1	192.168.10.105	CentOS7.9	2C/6G	工作节点	fluentd、elasticsearch
k8snode2	192.168.10.106	CentOS7.9	2C/6G	工作节点	fluentd、kibana

2. 案例拓扑

本案例架构如下图所示。

3. 案例需求

本案例的需求如下所示。

（1） 实现 Kubernetes 集群离线部署；

（2） 完成 EFK 部署并验证容器日志收集。

4. 案例实现思路