当前位置： 首页 > news >正文

k8s笔记02概述

news 2025/8/26 16:42:40

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为例）

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进程）PodK8s最小部署单位，包含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片段）
spec:containers:- name: app-container  # 容器名称（Pod内唯一）image: my-app:v1     # 容器镜像resources:           # 资源限制（可选）requests:          # 最小资源请求cpu: 100mmemory: 128Milimits:            # 最大资源限制cpu: 200mmemory: 256Miports:- containerPort: 8080  # 容器监听端口volumeMounts:          # 挂载存储卷（可选）- name: app-storagemountPath: /data     # 容器内挂载路径volumes:                 # 定义Pod级存储卷（可选）- name: app-storagepersistentVolumeClaim: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片段）
apiVersion: v1
kind: Service
metadata:name: nginx-service
spec:type: ClusterIP  # Service类型（默认ClusterIP）selector:        # 绑定Pod的标签（匹配labels: app=nginx的Pod）app: nginxports:- 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片段）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: nginx-ingressannotations: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片段）
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:replicas: 3  # 期望3个Pod副本selector:matchLabels:  # 匹配Pod标签（关联Pod）app: nginxtemplate:  # Pod模板（定义Pod的配置）metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2strategy:  # 更新策略（可选，默认滚动更新）type: RollingUpdaterollingUpdate:maxSurge: 1        # 最大超出副本数（更新时最多多1个Pod）maxUnavailable: 0  # 最大不可用副本数（更新时最少0个Pod不可用）

5. 配置管理：ConfigMap与Secret

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

（1）ConfigMap（非敏感配置）
  • 作用：存储明文配置（如应用配置文件、环境变量默认值）。
  • 配置示例（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片段）：
    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片段）：
    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片段）：
    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片段）
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. 完整工作流

  1. 用户发起请求：用户通过域名（如nginx.example.com）访问应用，请求先到达集群的Ingress控制器。
  2. Ingress路由转发：Ingress根据配置的规则（如域名+路径匹配），将请求转发到后端的nginx-service（Service对象）。
    • 关键配置：Ingress的spec.rules.http.paths.backend.service指定转发目标为nginx-service。
  3. Service负载均衡：nginx-service通过spec.selector（如app: nginx）匹配到一组后端Pod，将请求负载均衡分发到其中一个Pod。
    • 核心作用：屏蔽Pod动态IP，提供固定访问入口，确保请求稳定分发。
  4. Pod处理请求：Pod内的Nginx容器接收请求，处理后返回响应。Pod运行所需的配置（如nginx.conf）通过ConfigMap挂载到容器内，敏感信息（如证书密码）通过Secret注入，数据持久化依赖挂载的PVC（关联PV存储）。
  5. 控制器保障可用性：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）；缺点：依赖云厂商，有一定成本
emptyDirPod内容器间临时数据共享优点：Pod生命周期内有效，无需额外配置；缺点：Pod删除后数据丢失，仅适合临时数据（如日志缓存）

4. 控制器选择决策树

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

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

六、总结

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

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

相关文章：

  • C++|UDP通讯使用总结
  • HTML应用指南：利用GET请求获取MSN 天气数据并可视化
  • [系统架构设计师]应用数学（二十一）
  • list容器的使用
  • GNN:用MPNN（消息传递神经网络）落地最短路径问题模型训练全流程
  • 用 GSAP + ScrollTrigger 打造沉浸式视频滚动动画
  • 【Day 33】Linux-Mysql日志
  • DDR3入门系列（二）------DDR3硬件电路及Xilinx MIG IP核介绍
  • linux 正则表达式学习
  • 使用 gemini 来分析 github 项目
  • 安卓11 12系统修改定制化_____修改固件 默认给指定内置应用系统级权限
  • 大模型的思考方式
  • Java全栈开发实战：从Spring Boot到Vue3的项目实践
  • ZKmall开源商城多端兼容实践：鸿蒙、iOS、安卓全平台适配的技术路径
  • 8.25作业
  • [MH22D3开发笔记]2. SPI,QSPI速度究竟能跑多快，双屏系统的理想选择
  • Linux笔记9——shell编程基础-3
  • Tesseract OCR之页面布局分析
  • Linux系统的网络管理（一）
  • c# 读取xml文件内的数据
  • 网络编程-HTTP
  • zookeeper-znode解析
  • 【动态规划】309. 买卖股票的最佳时机含冷冻期及动态规划模板
  • 深入浅出 ArrayList：从基础用法到底层原理的全面解析（中）
  • 【C语言16天强化训练】从基础入门到进阶：Day 11
  • 信号处理的核心机制：从保存、处理到可重入性与volatile
  • 系统架构设计师-计算机系统存储管理的模拟题
  • 【数据结构】栈和队列——队列
  • AR远程协助：能源电力行业智能化革新
  • 数据库迁移幂等性介绍（Idempotence）（Flyway、Liquibase）ALTER、ON DUPLICATE