Kubernetes 核心概念与微服务架构解析
kubernetes核心概念
Kubernetes（简称 K8s）的核心概念是理解其集群管理逻辑的基础，以下从定义、核心特性、类比示例三个维度，对核心概念进行结构化梳理，更清晰地呈现各概念的定位与作用：
Pod：K8s 最小部署单元
核心定义
Pod 是 Kubernetes 中可创建、可管理的最小可部署计算单元，并非直接运行容器，而是作为 "容器组" 承载 1 个或多个紧密关联的容器。
关键特性
-
资源共享
：同一 Pod 内的所有容器共享 3 类核心资源：
- 网络：共享同一个网络命名空间（即共享 Pod 的 IP 地址和端口）；
- 存储：可通过
Volume挂载共享存储卷； - 运行声明：共享 Pod 层面的配置（如资源限制、重启策略等）。
-
生命周期与 Pod 一致：Pod 内任意容器故障，可能导致整个 Pod 重启（取决于重启策略），容器无法脱离 Pod 独立存在。
经典类比
用 "豌豆田" 模型理解 Pod 与其他资源的关系：
| 概念 | 类比对象 | 对应关系说明 |
|---|---|---|
| Container | 一颗豌豆 | 最小运行单元，依赖 Pod "包裹" |
| Pod | 一个豌豆荚 | 承载 1 颗或多颗豌豆（1 个或多个容器） |
| Node | 一根豌豆藤 | 承载多个豌豆荚（多个 Pod） |
| Cluster | 整个豌豆田 | 由多根豌豆藤（多个 Node）组成 |
Controller：Pod 的 "自动化管理者"
核心定义
Controller（控制器）是 K8s 中用于管理 Pod 生命周期、维持集群状态的核心对象，其核心逻辑是 "监控当前状态 → 对比期望状态 → 调整至期望状态"。
关键特性
- 状态驱动 ：每个 Controller 都有
spec字段定义 "期望状态"（如 Pod 副本数、运行规则），控制器持续监控集群 "当前状态"，自动修正偏差（如 Pod 故障时重启、副本数不足时新建）； - 资源关联：每个 Controller 至少关联一种 K8s 资源（主要是 Pod），不同 Controller 对应不同的业务场景。
经典类比
类似 "房间温度自动调节器"：
你设置的目标温度（期望状态）→ 调节器监控当前室温（当前状态）→ 自动开关空调（调整操作）→ 维持室温接近目标温度（达成期望状态）。
常见 Controller 类型及场景
| Controller 类型 | 核心作用 | 适用场景 | 关键特性 |
|---|---|---|---|
| Deployment | 部署无状态应用 | Web 服务、分布式无状态服务（如 Nginx、API） | Pod 可任意扩容缩容，无顺序 / 唯一性要求 |
| StatefulSet | 部署有状态应用 | 数据库（如 MySQL 主从）、分布式存储（如 ETCD） | Pod 有固定名称 / 网络标识，需按顺序启停 / 扩容 |
| DaemonSet | 部署集群守护进程 | 日志采集（如 Fluentd）、监控代理（如 Prometheus Node Exporter） | 每个 Node 上仅运行 1 个 Pod 副本，新 Node 自动部署 |
| Job | 执行一次性短期任务 | 数据备份、批量计算（如统计日志） | 任务完成后 Pod 自动终止，确保任务成功结束 |
| CronJob | 执行周期性定时任务 | 定时备份、定时清理日志 | 基于 Cron 表达式触发（如每天凌晨 3 点执行） |
Label：资源的 "多维度标签"
核心定义
Label 是附着在 K8s 资源（如 Pod、Node、Service）上的键值对（key=value） ，本身无业务逻辑，仅用于 "标记资源"，方便后续筛选和管理。
关键特性
- 灵活性：可在资源创建时指定，也可创建后动态添加 / 删除；
- 多维度：一个资源可绑定多个 Label（如 "环境 = 生产""版本 = v1.0""组件 = 前端"），支持按多维度分组；
- 用户主导：Label 的 key 和 value 由用户自定义，K8s 系统仅规定语法规则，不解读含义。
语法规则（key 与 value）
| 规则维度 | Label Key 要求 | Label Value 要求 |
|---|---|---|
| 长度限制 | 最多 63 个字符；若有前缀（DNS 子域，如k8s.example.com/），前缀最多 253 个字符 |
最多 63 个字符 |
| 字符规则 | 开头必须是字母 / 数字，中间可包含连字符（-）、下划线（_）、点（.） | 开头必须是字母 / 数字，中间可包含连字符（-）、下划线（_）、点（.） |
| 系统保留前缀 | 系统组件创建的 Label 必须带前缀，kubernetes.io/为 K8s 官方保留前缀 |
无特殊保留规则 |
常见 Label 示例
| 标签维度 | 示例（key=value） | 用途说明 |
|---|---|---|
| 环境 | environment=dev / environment=production |
区分开发 / 测试 / 生产环境的资源 |
| 版本 | release=stable / release=canary |
标记应用版本（稳定版 / 金丝雀版本） |
| 架构分层 | tier=frontend / tier=backend |
区分前端 / 后端 / 中间件组件 |
| 客户分区 | partition=customerA / partition=customerB |
按客户维度隔离资源 |
| 质量跟踪 | track=daily / track=weekly |
标记测试跟踪周期（每日构建 / 每周构建） |
Label Selector：资源的 "筛选器"
核心定义
Label Selector（标签选择器）是根据 Label 筛选 K8s 资源的工具，客户端（如用户、Controller）可通过它定位到符合条件的资源集合，实现 "精准操作"。
两种筛选类型
| 筛选类型 | 支持操作符 | 示例（筛选 Pod） | 说明 |
|---|---|---|---|
| 基于等式（Equality-based） | =、==（等于）、!=（不等于）；多条件用逗号分隔 | app=nginx（筛选 label 为 app=nginx 的 Pod）；app=nginx,environment=prod（同时满足两个条件） |
适合精确匹配或排除特定值 |
| 基于集合（Set-based） | in（在集合内）、not in（不在集合内）、!（不存在该 key）；空值（仅匹配 key 存在） | app in (nginx, apache)（筛选 app 为 nginx 或 apache 的 Pod）；!app（筛选没有 app 标签的 Pod） |
适合匹配多个值或判断 key 是否存在 |
经典类比
类似 SQL 语句的WHERE条件：
app=redis-slave的 Label Selector，等价于 SQL 查询：SELECT * FROM Pod WHERE Pod.label.app = 'redis-slave'。
Service：Pod 的 "网络入口"
核心定义
Service 是将一组 Pod 暴露为网络服务的抽象层，解决 Pod "动态性" 导致的访问问题 ------Pod 销毁 / 重建后 IP 会变化，Service 通过固定 IP 和端口，为前端提供稳定的访问入口。
核心价值
- 固定访问入口：Service 创建后会分配一个集群内唯一的 "Cluster IP"，即使后端 Pod IP 变化，Service IP 始终不变；
- 负载均衡：通过 iptables 或 ipvs 规则，将前端请求均匀转发到后端多个 Pod 副本（默认轮询策略）；
- 解耦前后端：前端无需知道后端 Pod 的具体 IP 和数量，只需访问 Service 的 IP + 端口即可。
场景示例
假设后端有 3 个 "图片处理 Pod"（副本数 = 3），前端需要调用图片处理服务：
- 为这 3 个 Pod 打相同 Label（如
app=image-processor）； - 创建 Service，通过 Label Selector（
app=image-processor）关联这 3 个 Pod； - 前端直接访问 Service 的 Cluster IP + 端口，请求会自动转发到后端任意一个 Pod，实现 "无感知访问" 和负载均衡。
Endpoints：Service 与 Pod 的 "桥梁"
核心定义
Endpoints 是维护 Service 后端 Pod 列表的资源，它会实时跟踪符合 Service Label Selector 的 Pod，自动更新 Pod 的 IP 和端口，确保 Service 的请求能转发到 "存活的 Pod"。
工作逻辑
- Service 创建时，会自动关联一个同名的 Endpoints 资源；
- Endpoints 持续监控集群中符合 Service Label Selector 的 Pod；
- 当 Pod 新建（符合条件）或销毁（故障 / 删除）时，Endpoints 会立即更新 "Pod IP: 端口" 列表；
- Service 转发请求时，直接从 Endpoints 获取后端 Pod 地址，无需自己监控 Pod 状态。
DNS：集群内的 "名称解析服务"
核心定义
K8s 集群内的 DNS 服务（如 CoreDNS）是为资源提供 "名称→IP" 解析的组件，避免用户 / 应用记忆复杂的 IP 地址，实现 "通过名称访问资源"。
两大核心功能
-
集群内 Service 解析：为每个 Service 生成一个默认的 DNS 域名（格式：Service名称.命名空间.svc.cluster.local），集群内 Pod 可通过该域名访问 Service，无需填写 Cluster IP；
示例：命名空间prod下的nginx-service，域名是nginx-service.prod.svc.cluster.local，Pod 通过该域名即可访问 Service。
-
Pod 访问互联网 ：为集群内 Pod 提供互联网域名解析（如解析
www.baidu.com的 IP），确保 Pod 能正常访问外部网络。
kubernetes核心概念之间的关系
Pod与Controller
Pod 和 Controller 靠 Label 建立关联，应用的伸缩、滚动升级等运维工作都由 Controller 完成。
案例：删除其中一个pod，查看controller自动创建新pod
bash
[root@master test]# kubectl get replicasets
NAME DESIRED CURRENT READY AGE
nginx-7854ff8877 3 3 3 4d22h
[root@master test]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-7854ff8877-4lss5 1/1 Running 5 (20h ago) 4d22h
nginx-7854ff8877-fzbfm 1/1 Running 5 (20h ago) 4d22h
nginx-7854ff8877-mrmww 1/1 Running 5 (20h ago) 4d22h
#删除一个会自动生成新的
[root@master test]# kubectl delete pod nginx-7854ff8877-mrmww
pod "nginx-7854ff8877-mrmww" deleted
[root@master test]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-7854ff8877-4lss5 1/1 Running 5 (20h ago) 4d22h
nginx-7854ff8877-8qcvp 0/1 ContainerCreating 0 4s
nginx-7854ff8877-fzbfm 1/1 Running 5 (20h ago) 4d22h
#查看控制器管理的标签Selector
[root@master test]# kubectl describe replicasets nginx-7854ff8877
Name: nginx-7854ff8877
Namespace: default
Selector: app=nginx,pod-template-hash=7854ff8877
Labels: app=nginx
pod-template-hash=7854ff8877
Annotations: deployment.kubernetes.io/desired-replicas: 3
deployment.kubernetes.io/max-replicas: 4
deployment.kubernetes.io/revision: 1
Controlled By: Deployment/nginx
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
pod-template-hash=7854ff8877
Containers:
nginx:
Image: nginx
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 78s replicaset-controller Created pod: nginx-7854ff8877-8qcvpPod与Service
Service 主要用于解决 Pod 动态变化导致的访问问题，承担服务发现功能，类似微服务架构中的注册中心。它的核心作用包括：
- 统一入口与负载分发：为一组功能相同的 Pod 提供固定访问地址，作为客户端请求的统一入口，并将请求自动负载均衡到后端各 Pod 实例。
- 关联与管控 Pod：通过标签（Label）与选择器（Selector）的匹配机制，动态关联并管控具有相同标签的 Pod 集合，即便 Pod 因调度、故障重建等原因发生 IP 变化，也能确保服务持续可用。
简言之，Service 既实现了后端 Pod 的自动发现与关联，又通过统一入口和负载均衡策略，保障了服务访问的稳定性与高效性。
bash
#查看所有service
[root@master test]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d23h
nginx NodePort 10.109.182.190 <none> 80:30578/TCP 4d22h
[root@master test]# kubectl get svc -n web-test
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tomcat-svc NodePort 10.102.244.64 <none> 80:30080/TCP 21h
#查看指定的service
[root@master test]# kubectl describe svc tomcat-svc -n web-test
Name: tomcat-svc
Namespace: web-test
Labels: <none>
Annotations: <none>
Selector: app=tomcat
Type: NodePort
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.102.244.64
IPs: 10.102.244.64
Port: <unset> 80/TCP
TargetPort: 8080/TCP
NodePort: <unset> 30080/TCP
Endpoints: 10.244.104.21:8080,10.244.166.154:8080
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>Service与DNS
通过DNS实现对Service名称解析，以此达到访问后端Pod目的。
bash
[root@master test]# kubectl get pods -n kube-system -o wide | grep dns
coredns-66f779496c-26pcb 1/1 Running 5 (21h ago) 5d 10.244.166.158 node1 <none> <none>
coredns-66f779496c-wpc57 1/1 Running 5 (21h ago) 5d 10.244.166.159 node1 <none> <none>
#获取集群ip
[root@master ~]# kubectl get service -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 7d
metrics-server ClusterIP 10.104.124.222 <none> 443/TCP 6d3h
#查看dns对应的pod地址
[root@master ~]# kubectl get endpoints -n kube-system
NAME ENDPOINTS AGE
kube-dns 10.244.166.178:53,10.244.166.181:53,10.244.166.178:53 + 3 more... 7d
metrics-server 10.244.104.46:10250 6d3h
#开始进行dns解析
[root@master test]# dig -t a tomcat-svc.web-test.svc.cluster.local. @10.96.0.10
; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7 <<>> -t a tomcat-svc.web-test.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63007
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tomcat-svc.web-test.svc.cluster.local. IN A
;; ANSWER SECTION:
tomcat-svc.web-test.svc.cluster.local. 30 IN A 10.101.98.15
#返回解析地址
;; Query time: 1 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Thu Nov 20 14:32:59 CST 2025
;; MSG SIZE rcvd: 119
#验证解析的地址
[root@master test]# kubectl get svc -n web-test
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tomcat-svc NodePort 10.101.98.15 <none> 80:30080/TCP 2m16s基于 Kubernetes 集群的容器化微服务解析
服务部署方式演进
单体服务架构
所有业务功能模块打包为一个整体应用，所有服务进程运行在同一台主机（或单一容器）内。
- 特点：架构简单、部署便捷，但扩展性差，单个模块故障可能导致整个应用不可用，迭代升级需整体重启。
分布式服务架构
将单体应用拆分为多个独立服务，服务进程分布在不同主机（或服务器）上，通过网络通信协同工作。
- 特点：单个服务故障不影响其他服务运行，可针对不同服务独立扩展，但缺乏统一的资源管理与调度机制，运维复杂度较高。
容器化微服务架构
基于容器化技术（如 Docker）封装分布式服务，依托 Kubernetes 等编排平台实现服务的部署、调度与治理。
- 核心优势：不仅继承分布式架构的独立性与扩展性，还实现服务高可用（故障自动恢复、副本冗余）、快速发布（滚动更新、灰度发布）、资源动态调度等能力，是当前主流的微服务落地方式。
Kubernetes 微服务组件关联关系（以 LNMT 应用为例）
LNMT 架构（Linux + Nginx + MySQL + Tomcat）是经典的 Web 应用架构，在 Kubernetes 集群中，可通过核心资源对象将其拆解为微服务部署，各组件对应关系清晰易懂：
集群与物理资源的类比
可将 Kubernetes 集群直接类比为一个 "虚拟 IDC 机房"，集群中的 Node 节点对应机房中的物理服务器，提供计算、存储、网络等基础资源，为微服务运行提供支撑。
应用组件与 K8s 资源的映射
- Nginx 服务：作为反向代理与负载均衡，通过 Deployment 控制器部署为无状态微服务，结合 Service（NodePort/LoadBalancer 类型）暴露外部访问入口，接收用户请求并转发至 Tomcat 服务。
- Tomcat 服务：作为应用运行容器（部署 Java Web 应用），通过 Deployment 控制器管理多副本，实现高可用，借助 Service（ClusterIP 类型）提供集群内访问地址，与 Nginx、MySQL 通过内部网络通信。
- MySQL 服务：作为数据存储组件，属于有状态服务，通过 StatefulSet 控制器部署，绑定 PersistentVolumeClaim（PVC）实现数据持久化，通过 Headless Service 提供稳定的网络标识，确保 Tomcat 服务始终能访问到正确的数据库实例。
- Linux 基础环境：由 Kubernetes 集群的 Node 节点（底层操作系统为 Linux）提供，无需额外部署，Kubernetes 自动管理节点资源，为所有容器化服务提供运行环境。
核心逻辑
Kubernetes 中的各类资源对象（Deployment/StatefulSet、Service、PVC 等）并非孤立存在，而是通过 "标签（Label）- 选择器（Selector）" 建立关联，形成完整的微服务生态：Nginx 接收外部请求 → 转发至 Tomcat 应用服务 → Tomcat 连接 MySQL 存储数据，全链路依托 Kubernetes 实现资源调度、故障自愈与服务治理。