k8s笔记02概述 - 技术栈

Kubernetes（K8s）YAML语法与核心对象学习笔记

一、K8s YAML语法核心结构

K8s中绝大多数资源对象的YAML配置文件，均由5个核心字段构成，不同对象仅在具体字段的子配置上存在差异，统一的结构便于标准化管理与操作。

核心字段	含义与作用	关键说明
`apiVersion`	创建对象所使用的K8s API版本	不同资源对象的API版本不同，例如： - 核心资源（Pod、Service）：`v1` - 应用控制器（Deployment）：`apps/v1` - ingress：`networking.k8s.io/v1`
`kind`	要创建的资源对象类型	明确资源类别，常见值包括： - 工作负载类：`Pod`、`Deployment`、`StatefulSet`、`Job` - 服务类：`Service`、`Ingress` - 配置存储类：`ConfigMap`、`Secret`、`PersistentVolume`
`metadata`	资源对象的元数据，用于唯一标识对象	核心子字段： - `name`：对象名称（同一命名空间内唯一） - `labels`：标签（键值对，用于资源关联与筛选，如Service绑定Pod） - `annotations`：注解（存储额外描述信息，如运维备注、工具配置） - `namespace`：命名空间（默认`default`，用于资源隔离）
`spec`	用户期望的资源对象状态，是资源配置的核心	定义对象的核心能力与属性，例如： - Pod的`spec.containers`（容器列表、镜像、资源限制） - Service的`spec.selector`（绑定Pod的标签匹配规则） - Deployment的`spec.replicas`（期望副本数）
`status`	资源对象的实际运行状态	只读字段，由K8s集群自动维护，用户无需配置。例如： - Deployment的`status.readyReplicas`（就绪副本数） - Pod的`status.phase`（运行阶段：Running、Pending、Failed）

语法示例（以Pod为例）

yaml 复制代码

apiVersion: v1  # API版本（核心资源用v1）
kind: Pod       # 资源类型为Pod
metadata:
  name: nginx-pod  # Pod名称
  namespace: default  # 命名空间（默认可不写）
  labels:
    app: nginx  # 标签（用于Service绑定）
spec:
  containers:  # 容器列表
  - name: nginx-container  # 容器名称
    image: nginx:1.14.2    # 容器镜像
    ports:
    - containerPort: 80    # 容器暴露端口

二、K8s核心对象与微服务映射关系

K8s的核心对象是对微服务架构中"流量路由、服务访问、实例运行、配置存储"等环节的抽象，可通过与传统虚拟机部署场景的映射，快速理解其作用：

1. 传统虚拟机场景 vs K8s对象映射

传统虚拟机部署环节	K8s对应核心对象	核心作用
流量网关（如Nginx网关）	`Ingress`	集群入口，实现HTTP/HTTPS层路由（如按URL路径路由到不同服务）、SSL终止
服务路由与负载均衡（如代理服务器）	`Service`	解决Pod动态IP问题，提供固定访问入口，实现后端Pod的负载均衡
应用实例（如虚拟机上的Tomcat进程）	`Pod`	K8s最小部署单位，包含1个或多个共享网络/存储的容器，运行实际业务
实例管理（如多实例启停、版本更新）	应用控制器（`Deployment`/`StatefulSet`等）	管理Pod生命周期，实现实例扩缩容、滚动更新、故障自愈
应用配置（明文配置文件）	`ConfigMap`	存储非敏感配置（如Nginx.conf、数据库连接地址），实现"配置与代码分离"
敏感信息（密码、令牌）	`Secret`	存储敏感信息（如数据库密码、API密钥），通过Base64加密，避免明文暴露
数据存储（如虚拟机本地目录、NAS）	`PV`/`PVC`	抽象存储资源，`PV`为集群级存储供应，`PVC`为应用级存储申请，实现存储与应用解耦
多项目/租户隔离（如独立虚拟机集群）	`Namespace`	逻辑隔离集群资源，实现多项目、多租户的权限与资源边界划分

三、核心对象详解

1. 最小部署单位：Pod

（1）核心定义

定位：K8s中创建和部署的最小单位，不可再分割。
组成：一个Pod可包含1个或多个容器（如业务容器+日志收集容器），容器间共享：
- 网络命名空间（同一Pod内所有容器共享一个IP地址）；
- 存储卷（可挂载同一PV/PVC，实现容器间数据共享）。
特性：Pod生命周期短暂，故障后会被控制器（如Deployment）重建，IP会动态变化（需通过Service访问）。

（2）关键配置（YAML片段）

yaml 复制代码

spec:
  containers:
  - name: app-container  # 容器名称（Pod内唯一）
    image: my-app:v1     # 容器镜像
    resources:           # 资源限制（可选）
      requests:          # 最小资源请求
        cpu: 100m
        memory: 128Mi
      limits:            # 最大资源限制
        cpu: 200m
        memory: 256Mi
    ports:
    - containerPort: 8080  # 容器监听端口
    volumeMounts:          # 挂载存储卷（可选）
    - name: app-storage
      mountPath: /data     # 容器内挂载路径
  volumes:                 # 定义Pod级存储卷（可选）
  - name: app-storage
    persistentVolumeClaim:
      claimName: app-pvc   # 关联PVC

2. 服务访问入口：Service

（1）核心定义

定位：为一组"功能相同、动态变化的Pod"提供固定访问入口，解决Pod IP动态变化的问题。
核心能力 ：
- 负载均衡：自动将请求分发到后端Pod；
- 服务发现：通过集群内DNS（如service-name.namespace.svc.cluster.local）访问，无需记IP。
常见类型 ：
- ClusterIP（默认）：仅集群内可访问，用于内部服务通信；
- NodePort：在集群所有节点暴露固定端口，外部可通过"节点IP:NodePort"访问；
- LoadBalancer：结合云厂商负载均衡器，外部可直接访问（需云环境支持）。

（2）关键配置（YAML片段）

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP  # Service类型（默认ClusterIP）
  selector:        # 绑定Pod的标签（匹配labels: app=nginx的Pod）
    app: nginx
  ports:
  - port: 80       # Service暴露端口（集群内访问端口）
    targetPort: 80 # 后端Pod的容器端口（与Pod的containerPort一致）

3. 集群入口网关：Ingress

（1）核心定义

定位：K8s的HTTP/HTTPS层入口控制器，相当于"集群级网关"，弥补Service仅支持四层（TCP/UDP）路由的不足。
核心能力 ：
- 路径路由：按URL路径将请求转发到不同Service（如/tomcat→Tomcat Service，/redis→Redis Service）；
- SSL终止：集中管理HTTPS证书，避免每个Service单独配置；
- 域名路由：按不同域名转发请求（如app1.example.com→App1 Service）。

（2）关键配置（YAML片段）

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /  # 路径重写（可选）
spec:
  ingressClassName: nginx  # 指定Ingress控制器（需提前部署，如Nginx Ingress Controller）
  rules:
  - http:
      paths:
      - path: /nginx        # 访问路径
        pathType: Prefix    # 路径匹配规则（Prefix=前缀匹配）
        backend:
          service:
            name: nginx-service  # 转发到的Service名称
            port:
              number: 80         # Service端口

4. 应用控制器：Deployment/StatefulSet/Job/CronJob/DaemonSet

这类控制器的核心作用是管理Pod的生命周期，根据应用类型提供不同的调度与运维能力，本质是对Pod的"扩展与封装"。

控制器类型	应用场景	核心特性
`Deployment`	无状态应用（如Tomcat、Nginx）	- 实例无状态，可任意扩缩容、替换 - 支持滚动更新、版本回滚 - 实例IP、名称不固定
`StatefulSet`	有状态应用（如Redis集群、MySQL主从）	- 实例有唯一标识（固定名称、IP） - 支持持久化存储与实例的"顺序启停" - 适合需保持状态的应用
`Job`	一次性任务（如数据备份、脚本执行）	- 任务执行完成后Pod自动终止 - 支持重试（任务失败时重新运行）
`CronJob`	定时任务（如每日凌晨3点备份数据）	- 基于Cron表达式调度（如`0 3 * * *`） - 本质是"定时创建Job"
`DaemonSet`	守护进程应用（如日志收集、监控代理）	- 集群内每个节点（或指定节点）运行1个Pod - 新节点加入时自动部署Pod，节点移除时自动删除

Deployment配置示例（YAML片段）

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3  # 期望3个Pod副本
  selector:
    matchLabels:  # 匹配Pod标签（关联Pod）
      app: nginx
  template:  # Pod模板（定义Pod的配置）
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
  strategy:  # 更新策略（可选，默认滚动更新）
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 最大超出副本数（更新时最多多1个Pod）
      maxUnavailable: 0  # 最大不可用副本数（更新时最少0个Pod不可用）

5. 配置管理：ConfigMap与Secret

两者均用于"配置与代码分离"，区别在于存储信息的敏感性，避免配置硬编码到镜像中。

（1）ConfigMap（非敏感配置）

作用：存储明文配置（如应用配置文件、环境变量默认值）。

配置示例（YAML片段） ：

yaml 复制代码

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:  # 键值对格式，key为配置名，value为配置内容
  nginx.conf: |  # 配置文件内容（多行用|表示）
    server {
      listen 80;
      server_name localhost;
      location / {
        root /usr/share/nginx/html;
        index index.html;
      }
    }
  app_env: "production"  # 单个环境变量

应用引用方式 ：
- 环境变量：在Pod的spec.containers.env.valueFrom.configMapKeyRef中引用；
- 卷挂载：将ConfigMap挂载为文件到Pod的指定目录（如/etc/nginx/nginx.conf）。

（2）Secret（敏感配置）

作用：存储敏感信息（如密码、API令牌、证书），数据通过Base64加密（注意：Base64是编码而非加密，生产环境需开启K8s加密配置）。

配置示例（YAML片段） ：

yaml 复制代码

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque  # 默认类型，存储任意敏感数据
data:  # 键值对，value需为Base64编码后的字符串
  db_username: YWRtaW4=  # 原内容：admin（Base64编码）
  db_password: MTIzNDU2  # 原内容：123456（Base64编码）

应用引用方式 ：
- 环境变量：在Pod的spec.containers.env.valueFrom.secretKeyRef中引用（K8s自动解码）；
- 卷挂载：挂载为文件到Pod，文件内容为解码后的明文。

6. 存储管理：PV与PVC

K8s通过PV（持久卷）和PVC（持久卷声明）实现"存储资源的供应与申请分离"，解耦存储管理员与应用开发者的职责。

（1）PV（Persistent Volume，持久卷）

定位：集群级别的"存储资源供应"，由管理员创建，代表一块实际的存储（如本地目录、NFS、云存储）。

关键配置（YAML片段） ：

yaml 复制代码

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv
spec:
  capacity:
    storage: 10Gi  # PV容量
  accessModes:
  - ReadWriteOnce  # 访问模式（RWO：仅单节点读写）
  persistentVolumeReclaimPolicy: Retain  # 回收策略（Retain：删除PVC后PV保留，需手动清理）
  storageClassName: standard  # 存储类（用于PVC匹配）
  hostPath:  # 存储类型为本地目录（仅测试用，生产用NFS/云存储）
    path: /data/local-pv

核心参数说明 ：
- accessModes（访问模式）：
  - ReadWriteOnce (RWO)：仅1个节点可读写；
  - ReadOnlyMany (ROX)：多个节点可只读；
  - ReadWriteMany (RWX)：多个节点可读写（需存储支持，如NFS）。
- persistentVolumeReclaimPolicy（回收策略）：
  - Retain：PVC删除后，PV保留数据，标记为"Released"，需手动处理；
  - Delete：PVC删除后，PV自动删除（适合云存储）；
  - Recycle：PVC删除后，PV自动清理数据并重新可用（已废弃，用Retain替代）。

（2）PVC（Persistent Volume Claim，持久卷声明）

定位：应用级别的"存储资源申请"，由开发者创建，用于绑定符合需求的PV，申请后PV仅能被该PVC使用。

关键配置（YAML片段） ：

yaml 复制代码

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-pvc
spec:
  accessModes:
  - ReadWriteOnce  # 需与PV的访问模式匹配
  resources:
    requests:
      storage: 5Gi  # 申请的存储容量（需≤PV容量）
  storageClassName: standard  # 需与PV的存储类匹配（仅匹配同存储类的PV）

应用引用方式 ：在Pod的spec.volumes.persistentVolumeClaim.claimName中关联PVC，将存储挂载到容器内指定目录。

7. 资源隔离：Namespace

（1）核心定义

定位：K8s的多租户与资源隔离工具，将集群划分为多个"逻辑子集群"，实现不同项目、团队的资源（Pod、Service、ConfigMap等）隔离，避免命名冲突与资源抢占。
核心特性 ：
- 同一Namespace内资源名称唯一，不同Namespace可重名；
- 支持资源配额（ResourceQuota）：限制Namespace内的CPU、内存总使用量；
- 支持权限控制（RBAC）：为不同Namespace配置不同的访问权限。

（2）配置示例（YAML片段）

yaml 复制代码

apiVersion: v1
kind: Namespace
metadata:
  name: dev-namespace  # 命名空间名称（如开发环境）

常用操作命令 ：
- 创建Namespace：kubectl create namespace dev-namespace；
- 在指定Namespace部署资源：kubectl apply -f

Kubernetes（K8s）YAML语法与核心对象学习笔记（续）

在指定Namespace部署资源：kubectl apply -f <配置文件> -n dev-namespace；
查看指定Namespace资源：kubectl get pods -n dev-namespace；
切换默认Namespace：kubectl config set-context --current --namespace=dev-namespace。

四、核心对象关联逻辑与工作流示例

以"用户访问Nginx应用"为例，串联K8s核心对象的协作流程，理解各对象如何共同支撑应用运行：

1. 完整工作流

用户发起请求 ：用户通过域名（如nginx.example.com）访问应用，请求先到达集群的Ingress控制器。
Ingress路由转发 ：Ingress根据配置的规则（如域名+路径匹配），将请求转发到后端的nginx-service（Service对象）。
- 关键配置：Ingress的spec.rules.http.paths.backend.service指定转发目标为nginx-service。
Service负载均衡 ：nginx-service通过spec.selector（如app: nginx）匹配到一组后端Pod，将请求负载均衡分发到其中一个Pod。
- 核心作用：屏蔽Pod动态IP，提供固定访问入口，确保请求稳定分发。
Pod处理请求 ：Pod内的Nginx容器接收请求，处理后返回响应。Pod运行所需的配置（如nginx.conf）通过ConfigMap 挂载到容器内，敏感信息（如证书密码）通过Secret 注入，数据持久化依赖挂载的PVC（关联PV存储）。
控制器保障可用性 ：nginx-deployment（Deployment控制器）实时监控Pod状态，若Pod故障（如容器崩溃），自动重建Pod；若需扩容，通过kubectl scale命令增加replicas，控制器会自动创建新Pod，维持期望副本数。

2. 核心对象关联图

复制代码

用户请求 → Ingress（域名/路径路由）→ Service（负载均衡）→ Pod（业务容器）
                          ↑               ↑               ↑
                          │               │               │
                 Ingress控制器      Deployment/StatefulSet   ConfigMap/Secret/PVC
                          │               （Pod管理）       （配置/存储支持）

五、关键补充说明

1. API版本选择原则

K8s不同资源对象的API版本会随版本迭代变化（如Deployment从extensions/v1beta1迁移到apps/v1），选择时需遵循以下原则：

优先使用稳定版本 （后缀无alpha/beta），如v1、apps/v1、networking.k8s.io/v1；
避免使用废弃版本（如extensions/v1beta1已在K8s 1.16+废弃），可通过kubectl api-resources查看当前集群支持的资源与API版本。
- 示例命令：kubectl api-resources | grep deployment，输出deployments deploy apps/v1 true Deployment，表明Deployment支持apps/v1版本。

2. 资源命名规范

K8s资源对象的metadata.name需遵循以下规范，避免创建失败：

长度不超过63个字符；
仅包含小写字母、数字、-（中划线），且不能以-开头或结尾；
示例：合法名称nginx-deployment-01，非法名称NginxDeployment（含大写）、nginx_deployment（含下划线）。

3. 存储类型选择建议

不同场景下需选择适配的PV存储类型，确保性能与可用性：

存储类型	适用场景	优缺点
`hostPath`	单机测试、临时存储	优点：配置简单；缺点：仅单节点可用，Pod调度到其他节点后无法访问，不适合生产环境
`NFS`（网络文件系统）	多节点共享存储（如StatefulSet应用）	优点：支持多节点读写（RWX），适合有状态应用；缺点：需额外部署NFS服务器，性能依赖网络
云存储（如AWS EBS、阿里云NAS）	生产环境、云原生部署	优点：高可用、自动扩缩容，支持K8s动态供应（StorageClass）；缺点：依赖云厂商，有一定成本
`emptyDir`	Pod内容器间临时数据共享	优点：Pod生命周期内有效，无需额外配置；缺点：Pod删除后数据丢失，仅适合临时数据（如日志缓存）

4. 控制器选择决策树

面对不同应用类型，可按以下逻辑选择合适的控制器：

应用是否为"长期运行服务"？
- 否（一次性任务）→ 选择Job；
- 是（长期运行）→ 进入下一步；
应用是否为"定时任务"？
- 是 → 选择CronJob；
- 否 → 进入下一步；
应用是否需要"每个节点运行1个实例"（如监控代理、日志收集）？
- 是 → 选择DaemonSet；
- 否 → 进入下一步；
应用是否为"有状态"（如需要固定名称/IP、持久化存储独立）？
- 是（如Redis集群、MySQL主从）→ 选择StatefulSet；
- 否（如Nginx、Tomcat）→ 选择Deployment。

六、总结

K8s的核心对象与YAML语法是集群操作与应用管理的基础，需重点掌握以下核心要点：

YAML结构 ：所有资源对象均基于apiVersion/kind/metadata/spec/status五字段构建，差异仅在spec的子配置；
对象关联 ：通过labels（标签）实现资源绑定（如Service绑定Pod、Deployment管理Pod），通过"Ingress→Service→Pod"实现流量链路，通过"ConfigMap/Secret→Pod""PV→PVC→Pod"实现配置与存储供应；
场景适配：根据应用类型（无状态/有状态/任务/定时任务）选择控制器，根据存储需求选择PV类型，根据隔离需求划分Namespace；
实践优先 ：需结合kubectl命令（如apply/get/describe/delete）实操，通过查看资源状态（kubectl get <资源> -o yaml）理解K8s对对象的维护逻辑，为后续深入学习（如动态存储、RBAC权限、集群监控）奠定基础。