开发-- k8s 常识

声明式编程

好的，这是一个非常核心的Kubernetes概念问题。我们来详细拆解一下。

分类

1）声明式API

这是Kubernetes的核心设计哲学。

  • 核心思想：用户向系统提交一个期望状态，系统负责不断地调整当前状态，使其与期望状态保持一致。用户不关心过程，只关心结果。
  • 操作方式：用户通过kubectl apply -f config.yaml来提交一个YAML/JSON文件。这个文件描述了“我期望这个Deployment有3个副本”。
  • 特点：
    • 幂等性：无论你apply多少次，只要最终提交的期望状态不变，结果都是一样的。系统会自动判断是否需要执行操作。
    • 状态驱动：系统内部有各种控制器，它们持续地观察当前状态，并将其与期望状态进行比对，然后驱动系统向期望状态收敛。
    • 自我修复：如果某个Pod意外崩溃，控制器会发现当前状态（2个Pod）与期望状态（3个Pod）不符，会自动创建一个新的Pod。
    • 可追溯性：YAML文件可以作为代码进行版本管理，清晰地记录了集群的配置历史。
    • 面向终态：用户关注“是什么”，而不是“怎么做”。

2）命令式操作

这是最直接、最像传统脚本的操作方式。

  • 核心思想：用户向系统发出一个具体指令，系统执行这个指令。用户关注的是“动作”和“过程”。
  • 操作方式：使用kubectl run, kubectl expose, kubectl edit, kubectl delete等命令。
    • 例如：kubectl run nginx --image=nginx 和 kubectl scale deployment nginx --replicas=3。
  • 特点：
    • 简单直接：对于快速测试和一次性任务非常方便。
    • 非幂等性：运行两次kubectl run nginx可能会创建两个同名Pod导致冲突。运行两次kubectl scale ... --replicas=3虽然结果正确，但本质是重复执行了命令。
    • 过程导向：用户需要发出一系列命令来达到目标状态。
    • 无状态记录：操作历史散落在命令行历史中，很难完整复现一个复杂应用的部署过程。
    • 缺乏自我修复：如果你用kubectl直接创建了一个Pod，它挂掉了就挂掉了，不会有控制器自动为你重建。

3）命令式对象配置

这种方式结合了配置文件和命令式命令。

  • 核心思想：用户提供一个配置文件，但使用命令式命令来让Kubernetes执行对该文件的操作。
  • 操作方式：使用kubectl create -f config.yaml（只能创建一次），kubectl replace -f config.yaml（替换），kubectl delete -f config.yaml（删除）。
  • 特点：
    • 配置文件化：配置可以被版本管理。
    • 非幂等性：kubectl create在资源已存在时会报错。你必须记住上次是create还是replace。
    • 操作显式：你需要明确告诉系统是“创建”、“替换”还是“删除”，系统不会自动判断该执行什么动作。
    • 易出错：在replace时，如果资源被其他人修改过，你的替换可能会覆盖掉别人的修改。

2. Kubernetes选用声明式API的原因

Kubernetes选择声明式API作为其核心范式，是基于其要管理的目标——大规模、分布式、复杂应用系统——的内在需求所决定的。

  1. 自动化与自我修复

    • 这是最根本的原因。在分布式系统中，故障是常态。声明式API将“期望状态”告诉系统后，系统就拥有了“自动驾驶”的能力。控制器可以持续工作，确保现实符合期望，无需人工干预。这是实现“云原生”弹性的基础。

  2. 幂等性与安全

    • 声明式API（特别是kubectl apply）是幂等的。无论操作执行多少次，结果都是一致的。这极大地简化了自动化脚本和CI/CD流程的编写，无需处理“资源已存在”等错误，使得操作更加安全和可靠。

  3. 分布式系统状态协调

    • Kubernetes本身就是一个分布式系统，其组件（如API Server, Controller Manager, Scheduler）需要协同工作。声明式API提供了一个清晰、统一的状态接口。所有组件都围绕这个“期望状态”工作，各自负责一部分，无需知晓对方的详细工作流程，实现了很好的解耦。

  4. 抽象与简化复杂性

    • 管理一个复杂的微服务应用，涉及部署、网络、存储、配置等多个维度。声明式API允许用户从“怎么做”的细节中解脱出来，只需关注“最终想要什么样子”。这降低了用户的心智负担，让管理复杂系统成为可能。

  5. 可审计与版本控制

    • 整个系统的蓝图（YAML文件）可以被存储在Git等版本控制系统中。任何对集群的变更都对应着一次代码提交，可以清晰地看到谁、在什么时候、为什么做了修改，便于审计、回滚和协作。

  6. 水平扩展与开放性

    • 声明式API配合控制器模式，是一个高度可扩展的框架。任何人都可以编写自定义资源（CRD）和控制器，来管理任何他们想要的资源（如数据库、中间件）。Kubernetes负责存储期望状态和提供基础平台，控制器负责实现业务逻辑。这种模式的成功催生了庞大的云原生生态系统。

3. 总结对比

模式 核心指令/思想 幂等性 自我修复 适用场景
命令式操作 kubectl run, scale 差 无 临时调试、一次性任务、学习
命令式对象配置 kubectl create/replace 差 无 简单脚本，但已被声明式取代
声明式API kubectl apply，期望状态 好 有 生产环境、CI/CD、GitOps、复杂应用管理

总而言之，Kubernetes采用声明式API不是偶然，而是为了应对现代应用在动态、不可靠的分布式环境中，对自动化、可靠性、可扩展性的根本要求所做出的必然选择。它将运维人员从繁琐的、重复的故障恢复和状态维护工作中解放出来。

Operator

Operator的本质是微服务的入口，各种服务以容器的方式进行交叉编织，完成各种流水线工作。
所以，

  1. 具体的业务请封装对应的容器，operator 负责维护容器的启停和生命周期。
  2. operator是一个运维工具，运维最原始的方式是while(1){监控各种长期存在的服务}。

CNI

  1. 多网卡CNI，POD里网卡之间的网络平面是不同享的，开发需要提前做好业务网卡的统一设置。
  2. POD 是可以通过容器的桥接，共用物理机的网卡通信。

PVC

  1. 现有的pvc是可以共同存在，提供不同的storageclass。如local_provisioner可以通过更改配置，实现安装两套绑定不同磁盘的storageclass。
  2. pvc支持存储的自动扩容 -- 1.26以上。
  3. pvc支持存储的缩容 -- 需要cdocker的底层能力（需要穿刺）。
posted @ 2025-08-01 17:34  静水深耕，云停风驻  阅读(13)  评论(0)    收藏  举报