K8S R&D: Kubernetes 日志收集、核心组件与集群管理全解析 - 指南
LogPilot 日志收集机制
日志类型与原理
LogPilot（阿里云开源工具）支持两类容器日志收集：
1 ) 标准化输出日志
- 存储路径：
/var/log/containers（Node 节点） - 由容器运行时自动映射至宿主机。
2 ) 容器内部日志
- 仅存于容器文件系统，需特殊采集策略。
- 需显式配置采集容器内文件路径（如
/app/logs/error.log）
3 ) 部署与配置流程
3.1 LogPilot 组件部署（DaemonSet）
以 DaemonSet 形式部署，确保每个 Node 节点运行一个 LogPilot Pod。
修改官方 YAML 文件关键参数：
- Elasticsearch 地址：指定日志存储的 ES 集群端点。
- 镜像源：可使用官方镜像或私有仓库镜像（示例为私有仓库地址）。
apiVersion: apps/v1 kind: DaemonSet metadata: name: log-pilot namespace: kube-system spec: template: spec: containers: - name: log-pilot image: registry.cn-hangzhou.aliyuncs.com/acs/log-pilot:0.9.7 # 官方/私有镜像 env: - name: PILOT_TYPE # 收集器类型（filebeat/fluentd） value: "filebeat" - name: ELASTICSEARCH_HOST # ES 集群地址 value: "es-cluster:9200" volumeMounts: - name: docker-sock mountPath: /var/run/docker.sock volumes: - name: docker-sock hostPath: path: /var/run/docker.sock部署命令：
kubectl apply -f logpilot-daemonset.yaml
3.2. 应用 Pod 日志采集规则
LogPilot 通过环境变量声明式配置识别需收集的日志，支持两种匹配方式：
- 环境变量模式：定义
aliyun_logs_{$name} = $path格式变量。{$name}：日志在 Elasticsearch 中的索引名称（如tomcatapplogs）。$path：日志路径类型标识：stdout：收集标准化输出日志。/path/to/logfile.log：收集容器内指定路径日志。
- 必须为日志目录挂载空卷（EmptyDir），否则采集失效。
- 环境变量格式：
aliyun_logs_<索引名> = <日志路径>- 收集
stdout：value: "stdout" - 收集容器内日志：
value: "/path/to/logfile.log"
- 收集
- 必须挂载空目录（EmptyDir）：
spec:
containers:
- name: tomcat
image: tomcat:9.0
env:
- name: aliyun_logs_tomcatapplogs # ES 索引名
value: "/usr/local/tomcat/logs/catalina.out" # 容器内日志路径
volumeMounts:
- name: log-volume
mountPath: /usr/local/tomcat/logs # 挂载点
volumes:
- name: log-volume
emptyDir: {} # 空卷挂载（必需）关键配置说明：
- 环境变量格式：
aliyun_logs_<索引名> value为stdout或容器内绝对路径- 必须挂载
emptyDir卷供 LogPilot 访问
Pod 亲和性（Affinity）与反亲和性（Anti-Affinity）
核心概念
| 策略类型 | 作用 | 强度 |
|---|---|---|
| 亲和性 | 将 Pod 调度至同一节点/拓扑域（如减少延迟） | 硬策略（必须满足） 软策略（尽量满足） |
| 反亲和性 | 避免 Pod 共存于同一节点/拓扑域（如故障隔离） | 硬策略（必须满足） 软策略（尽量满足） |
Pod亲和性 (Pod Affinity)：规则用于促使满足某些条件的Pod被调度到同一拓扑域（例如同一Node、同一机柜、同一可用区）。目的是将关联性强的Pod（如Web服务与缓存服务）部署在一起，减少网络延迟。
Pod反亲和性 (Pod Anti-Affinity)：规则用于避免满足某些条件的Pod被调度到同一拓扑域。常用于实现高可用，防止同一应用的多个副本集中在一个故障域内（如单台Node）。
配置示例
1 ) 亲和性实践
目标：将 pod2 强制调度至运行 pod1（标签 app=svc1）的节点
# pod2.yaml 配置片段
spec:
affinity:
podAffinity: # 亲和性定义
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["svc1"] # 匹配 pod1 的标签
topologyKey: kubernetes.io/hostname # 节点级拓扑域结果：pod2 副本均调度至 pod1 所在节点（如 k8s-node-1）
2 ) 反亲和性实践
目标：禁止 pod3 与 pod1（标签 app=svc1）共存于同一节点。
# pod3.yaml 配置片段
spec:
affinity:
podAntiAffinity: # 反亲和性定义
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["svc1"]
topologyKey: kubernetes.io/hostname结果：pod3 被调度至其他节点（如 k8s-node-2）。
效果说明：
- 亲和性可能导致节点负载不均衡
- 反亲和性提升跨节点容灾能力
持久卷（PV）生命周期
核心阶段详解
| 阶段 | 描述 | 关键操作 |
|---|---|---|
| Provisioning | PV 创建阶段 | 手动创建或 StorageClass 自动供给 |
| Binding | PV 与 PVC 绑定（匹配容量/访问模式） | PVC 发起绑定请求 |
| Using | Pod 挂载 PV 进行读写 | 通过 PVC 访问存储卷 |
| Releasing | PVC 删除后解绑 PV | PV 状态转为 Released |
| Reclaiming | 回收策略生效： • Retain：保留数据需手动清理 • Delete：自动删除 PV 及存储 | 策略由 PV 定义指定 |
| Available | PV 未绑定状态，等待重新使用 | 管理员可手动回收 |
| Failed | 回收/绑定过程中出错 | 需管理员介入修复 |
ETCD 核心特性与场景
1 ) 核心特性
- 强一致性 (Strong Consistency)：采用Raft共识算法，确保集群中所有节点数据高度一致，任何读操作都能获取最新的写入结果。
- 高可用性 (High Availability)：通过分布式部署（通常3、5、7个节点集群），容忍部分节点故障，保证服务持续可用。
- 持久性 (Persistence)：数据可靠存储到磁盘，防止进程重启导致数据丢失。
- 事务支持 (Transactions)：提供简单事务能力，保证多个操作的原子性（要么全部成功，要么全部失败），维护数据完整性。(示例：银行转账涉及扣款和入款两个操作，需事务保证原子性)。
- Watch机制 (Watch / Notifications)：支持客户端监听 (Watch) Key的变更，当Key的值发生创建、更新、删除时，ETCD能实时通知监听者。这是K8s控制器实现声明式API和协调循环的基础。
- 安全性 (Security)：支持基于TLS证书的客户端与服务端认证、节点间通信加密，以及基于RBAC的细粒度访问控制。
- 简洁API与轻量级：提供清晰定义的gRPC API和HTTP/JSON API，易于集成和使用。部署和维护相对简单。
2 ) 适用场景：
- 分布式系统元数据存储：作为Kubernetes的核心数据库，存储集群所有状态（Nodes, Pods, Services, Configs, Secrets等）。
- 服务发现 (Service Discovery)：存储服务名与后端实例地址映射，客户端通过查询或Watch获取最新服务端点。
- 分布式协调：利用其强一致性、Watch和租约(Lease)机制，实现分布式锁、Leader选举（如K8s控制器选主）、配置共享、任务队列等。
- 配置管理：存储和管理分布式系统或应用的配置信息，配置变更可通过Watch机制实时通知各节点。
3 ) 数据同步机制：
ETCD集群节点间通过Raft一致性算法实现数据同步。Raft算法确保：
- Leader选举：集群中存在唯一的Leader节点，负责处理所有客户端写请求。
- 日志复制 (Log Replication)：Leader将写操作以日志条目形式复制到Follower节点。当多数节点 (Quorum) 成功持久化日志后，Leader提交该条目并通知Followers提交，数据被应用到状态机。
- 安全性：保证已提交的日志在所有节点最终一致，且不会丢失。
Kubernetes 与 Docker 关系对比
1 ）关系
- Kubernetes 和 Docker 是互补的技术栈。
- Docker 提供了容器化的基础能力：定义容器镜像格式 (
Dockerfile)、构建镜像、提供容器运行时环境 (dockerd,containerd) 以运行和管理单个容器的生命周期。 - Kubernetes 是一个容器编排 (Orchestration) 系统，构建在容器运行时（如Docker, containerd, CRI-O）之上。它专注于管理大规模容器化应用，提供部署、调度、服务发现、扩缩容、自愈、配置管理等集群级能力。
- 简单比喻：Docker 像是能制造和发动单个引擎（容器），Kubernetes 像是管理和协调整支车队（容器集群）的调度系统。
2 ） 主要区别
| 维度 | Docker (Engine) | Kubernetes (K8s) |
|---|---|---|
| 管理对象 | 单个容器的生命周期 (创建、启动、停止、删除)。 | 容器集群：管理成百上千个容器（Pod）的编排、调度、运维。 |
| 核心功能 | 容器镜像管理、容器运行时、单机网络/存储。 | 容器编排、自动部署、服务发现、负载均衡、自动扩缩容、滚动更新、自愈、配置管理、存储编排、密钥管理。 |
| 架构组成 | 相对简单：dockerd守护进程、CLI工具。 | 复杂分布式系统：Master节点(API Server, Scheduler, Controller Manager, etcd)、Worker节点(kubelet, kube-proxy, 容器运行时)、插件(CNI, CSI, Ingress Controller等)。 |
| 网络模型 | 提供基础的单主机容器网络（如bridge网络）。 | 要求集群范围的Pod网络模型（Flat IP-per-Pod），依赖CNI插件（如Calico, Flannel, Cilium）实现跨节点Pod通信、网络策略等。 |
| 存储管理 | 提供卷(Volume)驱动，管理单机容器数据持久化。 | 提供持久卷(PV/PVC)抽象和存储类(StorageClass)，通过CSI插件对接各种分布式/云存储系统，实现集群级存储的动态供给和生命周期管理。 |
| 定位 | 容器引擎 (Container Engine)。 | 容器编排平台 (Container Orchestration Platform)。 |
| 调度能力 | 无 | 内置调度器（预选/优选算法） |
CNI (Container Network Interface) 网络模型
- 概念：CNI是一个标准规范（接口定义和工具库），用于在容器创建/删除时动态配置其网络。它并非具体实现，而是一个通用接口。
- 作用：解耦K8s（或其他容器平台）与具体的网络实现。K8s通过CNI调用CNI插件来管理Pod网络。
- 核心操作：
- ADD：容器创建时调用，负责分配IP地址、配置网络接口、设置路由等。
- DEL：容器删除时调用，负责释放IP地址、清理网络配置。
- 常见CNI插件：Calico, Flannel, Cilium, Weave Net等。它们实现了CNI规范，提供实际的网络功能（Overlay/Underlay网络、IPAM、网络策略等）。
- 工作流程：
kubelet在创建Pod的Infra容器（pause容器）时，根据--cni-conf-dir和--cni-bin-dir参数找到配置和插件。kubelet调用指定的CNI插件（通过/opt/cni/bin/下的二进制文件）。- CNI插件执行
ADD操作，配置Pod网络命名空间（NetNS）的网络栈（veth pair、IP地址、路由、可能连接Overlay网络）。 - 容器加入该Pod的NetNS，共享网络配置。
- 删除Pod时，
kubelet调用CNI插件执行DEL操作清理网络。
配置示例（Flannel）
{
"name": "flannel-net",
"type": "flannel",
"delegate": {
"isDefaultGateway": true,
"bridge": "cni0"
}
}配置示例（Calico）
{
"name": "k8s-pod-network",
"cniVersion": "0.3.1",
"plugins": [
{
"type": "calico",
"etcd_endpoints": "https://etcd-cluster:2379",
"ipam": { "type": "calico-ipam" }
}
]
}跨节点通信流程
Kubernetes 集群架构
节点角色与组件
| 节点类型 | 组件 | 核心职责 |
|---|---|---|
| Master | API Server | 集群入口，REST API 交互 |
| Controller Manager | 维护控制循环（副本数/节点状态） | |
| Scheduler | Pod 调度决策（预选+优选） | |
| etcd | 集群状态存储 | |
| Node | Kubelet | 管理 Pod 生命周期（创建/监控） |
| Kube-proxy | 服务负载均衡（iptables/IPVS 规则） | |
| Container Runtime | 容器运行时（containerd/CRI-O） |
Kubernetes 核心优势与场景
1 ） 核心优势
- 强大的容器编排能力：自动化部署、管理、扩展和运维大规模容器化应用。
- 声明式配置与自愈：用户声明期望状态（YAML），系统自动驱动并维持该状态。自动重启失败容器、替换不健康Pod、重新调度故障节点上的Pod。
- 高效的资源利用：优化集群资源分配，支持Pod资源请求(Requests)和限制(Limits)。
- 自动扩缩容：
- 水平Pod自动扩缩容 (HPA)：根据CPU、内存等指标自动调整Pod副本数。
- 垂直Pod自动扩缩容 (VPA)：自动调整Pod的资源请求和限制（Beta）。
- 集群自动扩缩容 (CA)：根据资源需求自动增减集群节点（需云提供商支持）。
- 服务发现与负载均衡：内置DNS服务和Service抽象，提供稳定的访问入口和流量分发。
- 配置与密钥管理：通过ConfigMap和Secret集中管理配置信息和敏感数据，并以卷或环境变量方式注入容器。
- 存储编排：通过PV/PVC/StorageClass抽象，支持动态供给和生命周期管理多种存储后端。
- 活跃的生态系统与可移植性：庞大且活跃的社区，丰富的工具和扩展（Helm, Operators, Istio等）。设计上避免厂商锁定，可在公有云、私有云、混合云或裸机上运行（可移植性）。
- 开源与标准化：由CNCF托管，是容器编排的事实标准。
2 ） 关键特点
- 可移植性 (Portability)：设计支持跨不同基础设施环境部署。
- 可扩展性 (Extensibility)：提供CRD (Custom Resource Definitions)、API Aggregation、Admission Webhooks、CNI/CSI/Device Plugins等机制，方便扩展API和功能。
- 自动化 (Automation)：核心设计原则，贯穿部署、调度、扩缩容、恢复等环节。
- 模块化与松耦合：组件设计清晰，通过定义良好的API交互。
3 ） 适用场景
- 微服务架构应用：天然适合管理大量独立部署、可扩展的微服务。
- 需要高可用和弹性的应用：自动故障转移、自愈和扩缩容保障业务连续性。
- 混合云与多云部署：统一管理运行在不同云或数据中心的容器化应用。
- 批处理任务与定时任务：通过Job和CronJob资源高效运行。
- 需要复杂部署策略的应用：支持蓝绿部署、金丝雀发布、滚动更新等。
- 资源敏感型应用：优化资源利用率，降低成本。
- 快速迭代和持续交付：与CI/CD工具链集成，实现快速部署和回滚。
Pod 网络通信机制
1 ) 同节点通信：
同一Node上的Pod通信：两个Pod位于同一Node时，通信不离开主机。它们通过各自的虚拟以太网设备(veth pair)连接到同一个网桥(如cni0)。网桥根据MAC地址表进行二层转发，通信延迟低、效率高。
- 通过本地网桥（如
cni0）直接转发。 - 通过 本地网桥（如 docker0 或 cni0） 直接通信，无需跨节点网络
2 ）跨节点通信：
不同Node上的Pod通信：两个Pod位于不同Node时，通信需要跨节点网络
这是由CNI插件实现的核心功能：
- CNI插件为每个Pod分配集群内唯一的IP地址。
- 插件建立跨主机网络通道：
- Overlay网络 (如Flannel VXLAN, Calico IPIP)：在物理网络之上封装Pod IP数据包。
- 路由方案 (如Calico BGP, Flannel host-gw)：配置主机路由表，告知其他Node如何到达非本机Pod网段。
- 源Pod发出的数据包，经源Node的CNI网络处理，通过底层网络（物理网络或Overlay隧道）到达目标Node。
- 目标Node的CNI网络解封装（如需要）并根据目标Pod IP将数据包送入目标Pod所在网络命名空间。
- 路由转发：Node 节点间通过路由表定向流量
- 路径：
Pod A → cni0 → flannel.1 → 宿主机网络 → 目标节点 flannel.1 → cni0 → Pod B
Kube-Scheduler 调度算法
两阶段调度流程
| 阶段 | 操作 | 示例策略 |
|---|---|---|
| 预选 (Predicates) | 过滤不符合条件的节点 | • 资源检查（CPU/Memory） • 端口冲突验证 |
| 优选 (Priorities) | 对节点评分并选择最优 | • 资源均衡（BalancedResourceAllocation） • 副本分散（SelectorSpreadPriority） |
Kube-Scheduler为Pod选择Node的过程分为两个主要阶段：
- 过滤 (Filtering) / 预选 (Predicates)：
- 目标：排除不满足Pod运行硬性要求的Node。
- 检查项：节点资源是否充足（CPU/Memory/GPU请求）、端口冲突、节点Selector/亲和性匹配、污点容忍度、卷区域限制等。
- 结果：获得一个可行Node列表。
- 打分 (Scoring) / 优选 (Priorities)：
- 目标：对过滤后的可行Node列表进行评分排序，选择最优Node。
- 评分策略：基于多种规则计算分数（可配置权重），例如：
LeastRequestedPriority/MostRequestedPriority：选择资源请求最少/最多的节点（均衡或紧凑利用）。BalancedResourceAllocation：平衡CPU和内存资源使用率。NodeAffinityPriority/InterPodAffinityPriority：满足节点亲和性/Pod间亲和性/反亲和性。TaintTolerationPriority：优先选择污点容忍度匹配更好的节点。SelectorSpreadPriority：尽量将相同Service或Controller的Pod分散到不同Node/Zone。
- 结果：选择总分最高的Node运行Pod。如果多个Node分数相同，则随机选择一个。
调度目标
- 最大化集群资源利用率
- 保障负载均衡与高可用
vue3)
vue3)
vue3)
vue3)
