【Kubernetes】（二）k8s基础

目录

[一、Kubernetes 集群架构：控制平面与工作节点](#一、Kubernetes 集群架构：控制平面与工作节点)

[1. 控制平面核心组件](#1. 控制平面核心组件)

[2. 工作节点核心组件](#2. 工作节点核心组件)

[3. 集群常用插件](#3. 集群常用插件)

二、标签与选择符

[1. 标签（Labels）](#1. 标签（Labels）)

标签的常见用途

标签的规范要求

[2. 标签选择符（Label Selectors）](#2. 标签选择符（Label Selectors）)

两种匹配类型

实操示例（贴合实际部署场景）

三、总结

---

一、Kubernetes 集群架构：控制平面与工作节点

一个完整的Kubernetes集群，本质是"决策中枢+执行终端"的协同体系，主要由两大核心部分构成：控制平面（Control Plane） 和 工作节点（Worker Nodes），两者各司其职、双向通信，共同保障集群稳定运行。

控制平面：作为集群的"大脑"，核心职责是做出全局决策（如Pod调度、资源分配），同时实时检测集群状态、响应各类异常事件（如Pod崩溃、节点故障）。为了保障高可用性，生产环境中控制平面通常部署在多台主机上，避免单点故障。

工作节点：作为集群的"生产终端"，核心职责是承载运行应用的Pod（容器组），维护容器运行时环境，同时实时向控制平面上报自身资源使用情况和Pod运行状态，接收并执行控制平面下发的各类指令。

1. 控制平面核心组件

控制平面的"决策能力"，依赖于多个功能独立、协同工作的核心组件，每个组件都承担着特定的职责，共同构成集群的"指挥体系"：

kube-apiserver：Kubernetes API的统一前端，是集群所有操作的唯一入口。无论是kubectl命令行操作、工作节点上报状态，还是外部系统调用，都必须经过它的认证、授权和限流处理。它支持水平扩展，可通过增加实例数量提升并发处理能力，是整个集群的"通信枢纽"。

etcd：集群的"核心数据库"，一款高可用、强一致性的分布式键值存储系统。集群内所有状态信息（如Pod配置、节点信息、标签、Service规则等）都统一存储在etcd中，且仅允许kube-apiserver直接读写，确保数据的安全性和一致性。

kube-scheduler：集群的"智能调度员"，负责监控所有新创建、未分配节点的Pod，结合多种因素（节点CPU/内存剩余资源、标签匹配规则、亲和性/反亲和性、污点与容忍度等），为每个Pod选择最合适的工作节点，确保资源高效利用。

kube-controller-manager：集群的"异常巡检与修复管家"，运行着多种控制器进程（如节点控制器、副本控制器、EndpointSlice控制器、Job控制器等）。核心职责是监控集群"实际状态"与"期望状态"的差异，一旦发现偏差（如Pod副本数不足、节点故障），立即触发修复操作，保障集群始终符合预设配置。

cloud-controller-manager：云环境专属的"适配桥梁"，嵌入了特定云厂商（如阿里云、腾讯云、AWS）的控制逻辑。核心作用是将Kubernetes集群与云提供商的API对接，实现集群与云服务的联动（如自动创建云负载均衡、云磁盘），仅在云环境部署的集群中需要启用，私有部署环境可忽略。

2. 工作节点核心组件

工作节点的"执行能力"，依赖于部署在每个节点上的3个核心组件，它们负责将控制平面的"决策指令"落地为实际的容器运行操作：

kubelet：控制平面在工作节点上的"专属代理"，运行在每一个工作节点上。核心职责是监听kube-apiserver下发的指令，确保Pod规范中描述的所有容器正常运行、处于健康状态；同时定期采集节点资源使用情况（CPU、内存、磁盘）和Pod运行状态，上报给控制平面，是连接控制平面与工作节点的"桥梁"。

kube-proxy：工作节点的"网络调度员"，负责维护节点上的网络规则（基于iptables或IPVS）。核心作用是实现Kubernetes Service的通信转发和负载均衡------实时监控Service和Pod的变化，更新网络规则，将外部请求或集群内其他Pod的请求，均匀转发到后端对应的多个Pod上，避免单点过载。

容器运行时（CRI）：容器的"生命周期管理器"，负责处理容器的创建、启动、停止、销毁等全生命周期操作，是Kubernetes与容器之间的标准化接口（CRI，Container Runtime Interface）。常见的容器运行时包括containerd、CRI-O等，早期常用的Docker，本质也是通过适配CRI接口接入K8s，目前已逐步被更轻量的containerd替代。

3. 集群常用插件

除了核心组件，Kubernetes集群还需要依赖各类插件，实现集群级的扩展功能。这些插件通常通过K8s自身的资源（如DaemonSet、Deployment）部署，与核心组件协同工作，完善集群能力：

网络与策略插件：如Calico、Flannel、Weave等，负责实现集群内Pod之间的网络连通性，同时提供网络策略管理（如限制Pod间的访问权限），是集群网络通信的基础。

服务发现插件：最常用的是CoreDNS，作为集群内的DNS服务器，负责解析Pod和Service的域名，实现服务发现（如Pod通过Service域名访问后端服务）。

可视化与控制插件：如Kubernetes Dashboard，提供Web UI控制台，支持通过图形化界面查看集群状态、操作Pod和Service，降低运维门槛。

基础设施插件：如KubeVirt，允许在Kubernetes集群上直接运行虚拟机，实现"容器+虚拟机"的混合部署，适配更多业务场景。

二、标签与选择符

Kubernetes集群中，会存在大量的Pod、Node、Service等资源对象，如何高效地对这些资源进行分类、筛选、调度和管理？核心就在于 标签（Labels） 和 选择符（Selectors） ------它们是K8s实现服务发现、Pod调度、批量操作的核心机制，简单且灵活。

1. 标签（Labels）

标签是附加在Kubernetes所有资源对象（如Pod、Node、Service、Deployment）上的键值对（key=value），本身不影响资源的功能运行，仅用于对资源进行标记、分类和识别，相当于给资源贴上"身份标签"。

标签的常见用途

服务发现与路由：Service通过标签选择符，匹配到对应的Pod，实现流量路由（如将请求转发到所有带有"app=nginx"标签的Pod）。

资源分类与环境隔离：通过标签区分不同环境、不同业务、不同版本的资源，如用"env=dev"标记开发环境资源、"env=prod"标记生产环境资源，"app=nginx"标记Nginx相关资源，"version=v1.0"标记1.0版本的资源。

批量操作与管理：通过标签筛选出一组资源，执行批量操作（如批量删除所有带有"version=v1.0"标签的Pod，批量更新所有带有"env=test"标签的Deployment）。

标签的规范要求

为了确保标签的可用性和一致性，K8s对标签的键（key）和值（value）有明确规范：

键名：必须以字母（a-z、A-Z）或数字（0-9）开头和结尾，中间可包含连字符（-）、下划线（_）、句点（.）；可选前缀（如"app.kubernetes.io/name"）必须是合法的DNS子域名。

值：长度不超过63个字符，可为空；同样以字母或数字开头和结尾，中间可包含连字符、下划线、句点。

2. 标签选择符（Label Selectors）

标签选择符是Kubernetes客户端（如kube-scheduler、Service、kubectl）识别和筛选一组资源的核心工具，本质是"根据标签的键值对，匹配符合条件的资源对象"。它支持两种常用匹配类型，可灵活组合使用：

两种匹配类型

基于等值匹配：匹配标签键值对完全相等或不相等的资源，常用符号：=（相等）、!=（不相等）。 示例："environment=production"（匹配所有标签为environment=production的资源）、"tier!=frontend"（匹配所有标签tier不等于frontend的资源）。

基于集合匹配：匹配标签值属于某个集合或不属于某个集合的资源，常用符号：in（属于）、notin（不属于）、!（不存在该标签键）。 示例："environment in (production, qa)"（匹配标签environment为production或qa的资源）、"tier notin (frontend, backend)"（匹配标签tier不属于frontend和backend的资源）、"!partition"（匹配没有partition标签的资源）。

实操示例（贴合实际部署场景）

给Pod定义标签 在Pod的配置文件中，通过metadata.labels字段定义标签，标记Pod的环境和应用类型：

apiVersion: v1
kind: Pod
metadata:
  name: label-demo-pod
  labels:
    environment: production  # 标记环境为生产环境
    app: nginx               # 标记应用为nginx
    version: v1.14.2         # 标记应用版本
spec:
  containers:
  - name: nginx-container
    image: nginx:1.14.2
    ports:
    - containerPort: 80  # 容器内部端口

使用nodeSelector调度Pod​通过nodeSelector标签选择符，让Pod只调度到带有特定标签的工作节点上（如GPU节点、高性能节点），实现精准调度：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-demo-pod
  labels:
    app: gpu-test
spec:
  nodeSelector:
    accelerator: nvidia-tesla-p100  # 只调度到带有该标签的节点
  containers:
  - name: gpu-container
    image: nvidia/cuda:11.0.3-base-ubuntu20.04
    command: ["sleep", "3600"]

kubectl命令行使用标签筛选​通过kubectl命令，结合标签选择符筛选资源，实现批量操作：

# 筛选所有生产环境的nginx Pod
kubectl get pods -l environment=production,app=nginx

# 批量删除所有v1.0版本的Pod
kubectl delete pods -l version=v1.0

三、总结

Kubernetes的设计哲学，核心是"解耦"与"可扩展"：控制平面与工作节点分离，实现"决策与执行"的解耦，保障集群的稳定性和可扩展性；控制平面内部组件各司其职、协同工作，工作节点组件专注执行，任何组件故障都可独立替换，不影响整体集群功能。

而标签与选择符，则为这种解耦架构提供了灵活的资源管理方式------无需修改资源本身的配置，仅通过标签标记和选择符筛选，就能实现资源的分类、调度、服务发现和批量操作，适配复杂多变的业务场景。

理解了这些核心概念，就掌握了Kubernetes的"骨架"和"逻辑"。后续学习Deployment、StatefulSet、Service等更复杂的资源对象时，就能清晰地知道这些资源如何与集群组件交互、如何通过标签实现关联，从而更高效地设计、部署和运维Kubernetes应用，让这个强大的容器编排平台真正为业务赋能。