K8S 学习笔记——核心概念与工作机制（二）

在上一章中，我们初步认识了 Kubernetes 的整体架构------Master-Worker 模型，并了解了各个核心组件的基本职责。本章我们将继续深入，学习 K8S 中几个最关键的核心概念和工作机制，这是理解和使用 Kubernetes 的基石。

---

一、Pod：K8S 的最小调度单元📦

什么是 Pod？

Pod 是 Kubernetes 中最小的、可部署和管理的计算单元。你可以把它想象成一个 "逻辑主机" ，它包含一个或多个紧密相关的容器，这些容器共享存储、网络和运行上下文。

为什么需要 Pod？

• 亲密性协作：有些容器需要紧密协作（比如一个容器写日志，另一个容器处理日志），它们需要共享存储卷、本地网络（localhost 通信）等资源。

• 生命周期一致：Pod 内的容器同时被创建、调度和销毁，保证了协作服务的生命周期一致性。

• 资源隔离与共享的平衡：容器之间可以通过 localhost 直接通信，共享 Volume，但又保持一定的隔离性。

Pod 示例（YAML 片段）

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: web-app
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: log-collector
    image: busybox:latest
    command: ["sh", "-c", "tail -f /dev/null"]

---

二、Service：服务发现与负载均衡

问题背景

Pod 是短暂的、可随时被销毁和重建的，它的 IP 地址也会随之变化。那么，其他服务如何稳定地访问到这些动态变化的 Pod 呢？

Service 的作用

Service 为一组 Pod 提供稳定的访问入口（一个固定的虚拟 IP 和 DNS 名称），并自动实现负载均衡。它是 K8S 中 服务发现 的核心机制。

三种常用类型

1. ClusterIP（默认）：在集群内部提供一个虚拟 IP，仅供集群内其他服务访问。

2. NodePort ：在 ClusterIP 基础上，在每个 Node 上开放一个端口（30000-32767），外部可通过 NodeIP:NodePort 访问。

3. LoadBalancer：基于云服务商的负载均衡器（如 AWS ELB、GCP LB），分配一个外部可访问的 IP。

Service YAML 示例

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app  # 选择具有标签 app=my-app 的 Pod
  ports:
  - protocol: TCP
    port: 80        # Service 端口
    targetPort: 8080 # Pod 内容器端口
  type: ClusterIP

---

三、 Ingress：集群入口与路由管理

为什么需要 Ingress？

Service 的 NodePort 或 LoadBalancer 虽然能暴露服务，但一个服务一个外部 IP/端口，不方便管理（端口冲突、成本高）。Ingress 提供了 HTTP/HTTPS 路由规则，让你可以通过一个入口（通常是一个 IP）根据域名或路径将流量分发到不同的后端 Service。

Ingress Controller

Ingress 只是一个规则声明，真正实现路由的是 Ingress Controller（如 Nginx Ingress Controller、Traefik），它负责监听 Ingress 规则并动态更新负载均衡器的配置。

Ingress 示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: blog.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blog-service
            port:
              number: 80
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

---

四、Volume 与持久化存储

容器存储的挑战

容器中的文件系统是临时的，容器重启后数据会丢失。而很多应用（如数据库）需要数据持久化。

Volume

Volume 是 Pod 中可被多个容器访问的共享目录，其生命周期与 Pod 绑定。K8S 支持多种 Volume 类型（emptyDir、hostPath、云存储等）。

PersistentVolume（PV）与 PersistentVolumeClaim（PVC）

为了解耦存储细节与应用定义，K8S 引入了两个概念：

• PersistentVolume（PV）：由管理员预先创建的存储资源（如云磁盘、NFS 等）。

• PersistentVolumeClaim（PVC）：用户对存储的"申请单"，Pod 通过 PVC 使用 PV。

PVC 示例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

然后在 Pod 中挂载：

spec:
  containers:
  - name: app
    image: my-app
    volumeMounts:
    - mountPath: "/data"
      name: storage
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: my-pvc

---

五、ConfigMap 与 Secret：配置与敏感信息管理

配置与代码分离

将配置信息（如环境变量、配置文件）从容器镜像中分离，便于不同环境（开发、测试、生产）使用同一镜像。

ConfigMap

用于存储非敏感的配置数据，以键值对或配置文件形式存在。

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  log_level: "info"
  config.properties: |
    server.port=8080
    cache.enabled=true

Secret

用于存储敏感信息（密码、令牌、密钥），以 Base64 编码存储（注意：Base64 不是加密，仅适合在集群内传输）。

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=  # admin
  password: cGFzc3dvcmQ=  # password

---

六、本章小结📝

概念	作用	类比
Pod	最小调度单元，包含一个或多个容器	一台逻辑服务器
Service	为 Pod 提供稳定的访问入口和负载均衡	负载均衡器 + 服务注册中心
Ingress	提供 HTTP/HTTPS 路由规则，统一入口	反向代理（如 Nginx）路由配置
Volume/PV/PVC	提供持久化存储，解耦存储细节	云硬盘 + 申请流程
ConfigMap/Secret	管理配置与敏感信息，实现配置与镜像分离	配置文件仓库 + 密钥管理器

这些核心概念构成了 Kubernetes 声明式 API 的基础。我们通过 YAML 文件描述"期望的状态"（比如"我需要一个包含 3 个副本的 Web 应用，使用某配置，挂载某存储"），K8S 会自动将其变为现实，并持续维持这个状态。