K8S R&D: Kubernetes 日志收集、核心组件与集群管理全解析

原创于 2025-11-11 08:45:00 发布 · 788 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器

K8S-R&D 专栏收录该内容

7 篇文章

订阅专栏

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、网络策略等）。
工作流程：
1. kubelet在创建Pod的Infra容器（pause容器）时，根据--cni-conf-dir和--cni-bin-dir参数找到配置和插件。
2. kubelet调用指定的CNI插件（通过/opt/cni/bin/下的二进制文件）。
3. CNI插件执行ADD操作，配置Pod网络命名空间（NetNS）的网络栈（veth pair、IP地址、路由、可能连接Overlay网络）。
4. 容器加入该Pod的NetNS，共享网络配置。
5. 删除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分数相同，则随机选择一个。