ELKStack 与 Kubernetes 核心基础知识点综合作业

1.请简述 Logstash 中 Filter 插件的核心作用，并列举 1 个你学习到的 Filter 插件的常见使用场景

核心作用：Filter 插件是 Logstash 数据处理流程的核心，负责对采集到的原始日志数据进行清洗、转换、提取、过滤等操作，将非结构化 / 半结构化数据标准化为结构化数据（如提取关键字段、格式化时间、过滤无效日志），为后续 Elasticsearch 存储和 Kibana 分析提供高质量数据。

举例：以 grok 插件为例，常用于解析 Nginx 访问日志。

例如，Nginx 原始访问日志格式为 192.168.1.1 - - [10/Oct/2024:13:55:36 +0800] "GET /index.html HTTP/1.1" 200 1234，

通过 grok 模式 %{IP:client_ip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATH:path} %{URIPROTO:protocol}/%{NUMBER:http_version}" %{NUMBER:status_code} %{NUMBER:response_size}，

可自动提取出 client_ip（客户端 IP）、timestamp（访问时间）、method（请求方法）等结构化字段，方便后续按字段筛选、统计

2.在 ELKStack 处理电商业务日志的流程中，Filebeat 负责的工作是什么？Logstash 在这个流程里的核心职责是什么？

Filebeat 的工作：作为轻量级日志采集器，部署在电商业务服务器（如商品服务、订单服务、支付服务）上，负责实时监控并采集业务日志（如订单创建日志、支付回调日志、接口报错日志）、Nginx 访问 / 错误日志等，通过轻量级传输协议（如 TCP）将原始日志数据发送至 Logstash 或 Elasticsearch，核心特点是资源占用低，适合分布式部署在大量业务节点上。

Logstash 的核心职责：作为日志处理中间件，接收 Filebeat 采集的原始日志，通过 Filter 插件完成数据清洗（过滤测试环境日志）、结构化转换（提取订单号、用户 ID、支付金额等核心字段）、数据 enrichment（补充地理位置信息、关联用户画像标签），最后将标准化的结构化数据转发至 Elasticsearch 存储，同时可实现日志分流（如将支付日志和商品浏览日志分别写入不同索引）。

3.将 Nginx 访问错误日志通过 Filebeat 收集后，分别发送至 Redis、Kafka 作为缓存组件，请问这两种组件作为日志缓存时，最核心的差异是什么？

最核心差异 ：消息可靠性与消费模式的适配场景不同，具体体现在：

Redis 作为缓存：基于内存存储，日志数据以列表（List）形式存储，核心优势是读写速度快、部署简单；但可靠性较弱（默认无持久化或持久化性能一般，宕机易丢失数据），且不支持复杂的消费组机制，适合日志流量较小、对数据丢失容忍度较高、追求低延迟传输的场景。

Kafka 作为缓存：基于磁盘存储，日志数据以主题（Topic）形式分区存储，核心优势是高可靠性（支持多副本备份，宕机不丢数据）、高吞吐量（支持每秒百万级消息传输）、支持消费组机制（可实现多 Logstash 实例并行消费，避免单点瓶颈），适合电商等日志流量大、对数据可靠性要求高、需要分布式消费的场景。

4.请说出 Kubernetes 的三大接口规范分别是什么，并简要说明其中任意 1 种的作用

三大接口规范：CRI（容器运行时接口）、CNI（容器网络接口）、CSI（容器存储接口）。

作用说明（以 CRI 为例）：CRI 是 Kubernetes 与容器运行时（如 Containerd、CRI-O）之间的标准化接口，定义了创建 / 删除容器、启动 / 停止容器、获取容器状态等核心操作的规范。其核心作用是解耦 Kubernetes 与底层容器运行时，使 Kubernetes 无需关注容器运行时的具体实现细节，只要容器运行时符合 CRI 规范，即可接入 Kubernetes 集群（如替换 Docker 为 Containerd 时，无需修改 Kubernetes 核心代码），提高了集群的灵活性和可扩展性。

5.Pod 是 Kubernetes 的最小部署调度单元，请简述 Pod 的启动流程的核心步骤

用户提交请求 ：通过 kubectl apply -f pod.yaml 提交 Pod 创建请求，API Server 接收并验证请求的合法性（如语法、权限）。
API Server 存储状态：验证通过后，API Server 将 Pod 的期望状态（如镜像、资源限制）存储到 etcd 中。
调度器（kube-scheduler）调度：调度器监听 API Server 中未绑定节点的 Pod，通过调度算法（如节点资源利用率、亲和性规则）选择合适的节点，将 Pod 绑定到该节点，并将绑定结果更新至 API Server。
kubelet 启动 Pod ：目标节点上的 kubelet 监听 API Server，发现绑定到自身的 Pod 后，通过 CRI 调用容器运行时（如 Containerd）：
- 拉取 Pod 所需的镜像（如 nginx:1.24）；
- 创建 Pod 对应的网络命名空间、存储卷（如 EmptyDir、PVC）；
- 启动 Pod 中的容器（先启动初始化容器 initContainer，再启动业务容器 container）。
更新状态：容器启动成功后，kubelet 将 Pod 的实际状态（如 Running）更新至 API Server，API Server 同步至 etcd，整个启动流程完成。

6.Kubernetes 中用于 Pod 健康状态检查的三种探针分别是什么？请简要描述其中 1 种探针的适用场景

三种探针：存活探针（livenessProbe）、就绪探针（readinessProbe）、启动探针（startupProbe）。

适用场景（以就绪探针为例） ：就绪探针用于检测 Pod 中的业务容器是否已准备就绪，能够正常接收请求。适用场景：电商系统中的订单服务 Pod，启动后需要连接数据库初始化配置、加载缓存数据（可能需要 30 秒），此时 Pod 虽处于 Running 状态，但尚未具备服务能力。通过配置就绪探针（如检测 /health/ready 接口返回 200 状态码），Kubernetes 会在探针检测成功后，才将该 Pod 加入 Service 的负载均衡池，避免将用户请求转发至未就绪的 Pod，从而保证服务可用性。

7.请简述 Deployment 控制器的主要作用，以及它和 ReplicaSet 控制器的关系

Deployment 的主要作用 ：Deployment 是 Kubernetes 中用于管理无状态应用的核心控制器，基于 ReplicaSet 封装，提供更高级的 Pod 管理能力，核心作用包括：
1. 确保 Pod 按照期望副本数运行（如维持 3 个 Nginx Pod 实例）；
2. 支持 Pod 版本更新（如滚动更新、金丝雀更新），并可在更新失败时回滚至历史版本；
3. 支持扩缩容（手动扩缩容或通过 HPA 自动扩缩容）；
4. 提供声明式配置（通过 YAML 文件定义期望状态，Kubernetes 自动协调实际状态）。
与 ReplicaSet 的关系 ：
1. 父子关系：Deployment 不直接管理 Pod，而是通过管理 ReplicaSet 间接管理 Pod（每个 Deployment 对应一个或多个 ReplicaSet）；
2. 版本控制：Deployment 的每次更新（如镜像版本变更）都会创建一个新的 ReplicaSet，旧的 ReplicaSet 会被保留（可配置保留数量），用于回滚；
3. 职责分工：ReplicaSet 的核心职责是确保 Pod 副本数符合期望，无版本管理和回滚能力；Deployment 在 ReplicaSet 的基础上，增加了版本更新、回滚、扩缩容策略等高级功能，简化了无状态应用的运维管理。