分布式系统

K8s 掌握

K8s的架构组织

• 主从分布式架构，分为Control Plane (Master节点) 和 Node (工作节点)
• Control Plane负责集群的状态和配置，全局的调度、扩容和更新
  • kube-apiserver (API服务器)： k8s集群的api入口（唯一），提供资源的各种增删改查(CRUD)操作
  • etcd，作为K8s集群的**数据库，**存储集群的所有状态和配置信息（如Pod定义、节点信息、服务发现数据）；采用强一致性（Raft共识算法）；etcd宕机后集群只读不可写，已运行的Pod不受影响，但无法创建、删除、扩容资源
  • kube-scheduler，负责为新创建的Pod选择最合适的Node节点运行；主要根据资源的请求（Request/Limit）以及亲和性（Pod与Node、Pod与Pod之间的偏好）；分为predicate预选过滤不符合要求的节点以及priority优选，优先级排序选择优先级最高的节点两个阶段
  • controller-manager: 是k8s的大脑，通过apiserver监控整个集群的状态，确保集群处于预期的工作状态；Replication Controller确保在集群中运行指定数量的Pod副本；Deployment用于定义应用程序的部署、管理ReplicaSet，并提供滚动更新、回滚等功能
• Node, 独立主机（物理机/虚拟机），运行容器化应用
  • Kubelet, Node节点的核心管家，负责管理本节点上的Pod生命周期，是Control Plane和Node之间的“桥梁”; 监控Pod状态、挂载Pod所需的存储卷
  • kube-proxy: 负责节点的网络规则管理，实现K8s Service的负载均衡和服务发现；控制转发流量
  • Container Runtime: 负责容器的创建，运行和销毁，是K8s与容器之间的接口

K8s的基础组件

• Pod 为k8s 的最小调度单元，里面会包含一个或者多个容器(Container), Pod内的容器共享存储及网络，可通过localhost通信
• Deployment: pod上层的一个抽象，可以定义一组Pod的副本数量，以及这个pod的版本，一般用Deployment来做应用的真正的管理，而Pod是组成Deployment的最小单元
• Service: Pod是不稳定的，IP会发生变化，因此需要一层抽象来屏蔽这种变化，Service可以实现，其主要功能为：
  • 提供访问一个或者多个Pod实例稳定的访问地址
  • 支持多种访问方式ClusterIP (对集群内部访问) NodePort(对集群外部访问) LoadBalancer (集群外部负载均衡)
• Volume: 表示存储卷，Pod访问文件系统的抽象层，具体的后端存储可以是本地存储、NFS网络存储、云存储以及分布式存储等
• NameSpace: 用以资源的逻辑隔离，同一个Namespace 中资源命名唯一；不同Namespace中资源可重名；

CRD

• 如何在CRD中控制多个版本的迭代

  首先需在 CRD YAML 中声明多个版本，定义不同版本的具体schema信息等等

  spec.versions.storage 字段，用于指示使用哪个版本的 CRD 持久化到存储中。在一个 CRD 定义中，只能有一个版本的 storage 字段的值为 true。

  使用 webhook 实现多版本数据转换的策略来解决多版本兼容性问题

Raft共识算法

Raft算法的首要设计目标是易于理解与实现，它将分布式共识这一复杂问题结构化为几个清晰的状态和流程。在Raft中，每个服务器节点在任何时刻都扮演着领导者、跟随者或候选人这三种明确角色之一，通过一个任期的递增逻辑来标识集群的时代变迁，这为算法提供了清晰的时序上下文。其运作的核心循环始于领导选举：当跟随者在超时周期内未能收到领导者的心跳，便会递增任期并转变为候选人发起选举；获得集群中多数节点投票的候选人将成为新任领导者。选举成功的关键在于Raft施加的严格限制——只有那些拥有最新、最完整日志的节点才有资格赢得选举，这确保了已提交的日志条目不会被覆盖。

一旦领导者确立，系统便进入日志复制阶段。所有客户端请求均由领导者处理，领导者将其作为日志条目复制到所有跟随者。当一个条目被成功复制到集群的多数节点时，领导者便会提交该条目，并通知跟随者将其应用到各自的状态机中，从而达成状态一致。Raft通过维护一系列日志匹配特性和领导人完全特性来保证安全性，例如领导者永远不会覆盖已提交的条目，并且只有领导者的日志条目才会被复制。这种以强领导人为中心的模型，相较于Paxos的对称式设计，极大地简化了系统在正常操作和异常恢复时的行为逻辑与工程实现。

Ray

Ray是一个为构建和运行分布式应用程序而设计的统一计算框架，其核心抽象旨在以极简的API同时支持无状态的任务并行和有状态的Actor模型。在Ray中，任务代表一个无状态的远程函数执行，而Actor则代表一个有状态的工作进程，两者都可通过简单的Python装饰器进行声明。这种设计允许开发者用近乎编写单机程序的思维模式来构建复杂的分布式应用，例如机器学习训练流水线或实时模拟服务。

Ray的高性能源自其精心设计的底层系统架构。其全局控制存储负责以对象为中心的方式管理分布式内存，通过所有权机制和分布式引用计数实现高效的对象共享与自动垃圾回收。其自底向上的分布式调度器将调度决策尽可能地推送给拥有数据的节点，并通过任务窃取机制实现工作负载的动态平衡，从而在运行数百万个细粒度任务时仍能保持极低的延迟与高吞吐。Ray的另一个关键特性是其分层化的架构，它将应用层的API与系统层的核心服务解耦，使得Ray可以无缝地从单机扩展到大规模集群，并支持从强化学习、超参数搜索到数据处理的多样化工作负载，成为AI基础设施中连接算法开发与大规模生产部署的重要桥梁。