Kubernetes

今天我们来看看 kubernetes 和 gitops 的理论实践 命令介绍 首先我们来看看 kubectl 支持的子命名，方便我们使用： kubectl apply - 应用一个或多个资源的定义。通常用于部署应用程序或更新资源。 kubectl get - 显示一个或多个资源的信息。这是查看 Kubernetes 集群中资源状态的常用命令。 kubectl describe - 显示一个或多个资源的详细信息，如事件、状态和配置。 kubectl delete - 删除 Kubernetes 集群中的资源。 kubectl exec - 在集群中的容器里执行命令。 kubectl logs - 打印容器的日志。 kubectl create - 从文件或标准输入中创建一个或多个资源。 kubectl edit - 编辑集群中的资源。这将打开一个编辑器来修改资源的配置。 kubectl port-forward - 将本地端口转发到集群中的 Pod。 kubectl run - 在集群中运行一个指定的镜像。 kubectl scale - 调整资源（如 Deployment、ReplicaSet）的副本数量。 kubectl rollout - 管理资源的部署，如查看状态、暂停、恢复或回滚更新。 除了上面的命令，Kubernetes 中的 kubectl 还支持注解： kubectl annotate 命令用于给 Kubernetes 集群中的资源添加或更新注解（annotations）。注解是一种附加信息，可以用于存储非识别性的元数据。它们通常用于管理工具、库和客户端以存储辅助信息，例如描述、版本信息等。...

Kubelet组件解析 理解 kubelet Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命： １．监视分配给该Node节点的pods ２．挂载pod所需要的volumes ３．下载pod的secret ４．通过docker/rkt来运行pod中的容器 ５．周期的执行pod中为容器定义的liveness探针 ６．上报pod的状态给系统的其他组件 ７．上报Node的状态 kubelet 管理Pod的核心流程主要包括三个步骤。首先，kubelet获取Pod清单，可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取。其次，节点管理主要是节点自注册和节点状态更新，Kubelet在启动时通过API Server注册节点信息，并定时向API Server发送节点新消息，API Server在接收到新消息后，将信息写入etcd。最后，Pod启动流程主要包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 kubelet是Kubernetes中的一个节点代理程序，负责维护本节点上Pod的生命周期。kubelet是Kubernetes中非常重要的组件之一，它在Kubernetes集群中扮演着非常重要的角色。kubelet可以在每个节点上运行，它监视分配给该Node节点的pods，并执行各种管理容器的操作，如挂载pod所需要的volumes、下载pod的secret等。 kubelet的核心流程主要包括获取Pod清单、节点管理和Pod启动流程。其中，获取Pod清单的方式包括文件、HTTP endpoint、API Server和HTTP server等方式。节点管理主要包括节点自注册和节点状态更新，而Pod启动流程主要包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 在节点管理方面，kubelet可以通过设置启动参数-register-node来确定是否向API Server注册自己。如果kubelet没有选择自注册模式，则需要用户自己配置Node资源信息，同时需要告知kubelet集群上的API Server的位置。在启动时，kubelet会通过API Server注册节点信息，并定时向API Server发送节点新消息，API Server在接收到新消息后，将信息写入etcd。 在Pod管理方面，kubelet可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取Pod清单。文件方式主要用于static pod，而HTTP和API Server方式则是Kubernetes中常用的方式。HTTP server主要用于kubelet侦听HTTP请求，并响应简单的API以提交新的Pod清单。 在Pod启动流程方面，kubelet会执行各种管理容器的操作，包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。镜像拉取是Pod启动过程中的一项重要工作，kubelet可以通过imageManager模块来管理镜像。容器启动是Pod启动过程的下一步，kubelet通过container runtime来启动容器。探针监控是Pod启动过程中一项非常重要的工作，kubelet会周期性地执行pod中为容器定义的liveness探针，并将结果上报给系统的其他组件。状态汇报是kubelet的一个重要功能，它会上报pod和Node的状态给系统的其他组件，以及上报节点自身的状态和资源使用情况给API Server。 总之，kubelet是Kubernetes中非常重要的组件之一，它负责维护本节点上Pod的生命周期，并执行各种管理容器的操作。kubelet的核心流程包括获取Pod清单、节点管理和Pod启动流程。在节点管理方面，kubelet通过设置启动参数-register-node来确定是否向API Server注册自己。在Pod管理方面，kubelet可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取Pod清单。在Pod启动流程方面，kubelet会执行各种管理容器的操作，包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 kubelet 架构 每个节点上都运行一一个 kubelet 服务进程，默认监听 10250 端口。 接收并执行 master 发来的指令; 管理 Pod 及 Pod 中的容器; 每个 kubelet 进程会在 API Server上注册节点自身信息，定期向 master 节点汇报节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。 kubelet 架构如下图所示：...

调度器 kube-scheduler 负责分配调度 Pod 到集群内的节点上,它监听 kube-apiserver,查询还未分配 Node 的 Pod,然后根据调度策略为这些 Pod 分配节点(更新 Pod 的 NodeName 字段)。 调度器需要充分考虑诸多的因素： 公平调度; 资源高效利用; QoS; affinity 和 anti-affinity; 数据本地化(data locality) ; 内部负载干扰(inter-workload interference) ; deadlines。 kube-scheduler 调度分为两个阶段, predicate 和 priority: predicate: 过滤不符合条件的节点; priority:优先级排序，选择优先级最高的节点。. predicate 策略 PodFitsHostPorts：检查是否有 Host Ports 冲突。 PodFitsPorts：同P odFitsHostPorts。 PodFitsResources：检查 Node 的资源是否充足，包括允许的Pod数量、CPU、内存、GPU个数以及其他的OpaqueIntResources。 HostName：检查 pod.Spec.NodeName 是否与候选节点一致。 MatchNodeSelector：检查候选节点的 pod.Spec.NodeSelector 是否匹配 NoVolumeZoneConflict：检查 volume zone 是否冲突。 MatchInterPodAffinity：检查是否匹配 Pod 的亲和性要求。 NoDiskConflict：检查是否存在 Volume 冲突，仅限于 GCE PD、AWS EBS、Ceph RBD以及 iSCSI。 PodToleratesNodeTaints：检查 Pod 是否容忍 Node Taints。 CheckNodeMemoryPressure：检查 Pod 是否可以调度到 MemoryPressure 的节点上。 CheckNodeDiskPressure：检查 Pod 是否可以调度到 DiskPressure 的节点上。 NoVolumeNodeConflict：检查节点是否满足 Pod 所引用的 Volume 的条件。 priority 策略 SelectorSpreadPriority：优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量。 尽量将同一个 rc 下的多个副本分散到不同节点，增加可用性 InterPodAffinityPriority：优先将Pod调度到相同的拓扑上(如同一个节点、Rack、Zone等)。 LeastRequestedPriority：优先调度到请求资源少的节点上。 BalancedResourceAllocation：优先平衡各节点的资源使用。 NodePreferAvoidPodsPriority：alpha....

容器运行时 容器运行时(Container Runtime)，运行于Kubernetes (k8s)集群的每个节点中，负责容器的整 个生命周期。其中Docker是目前应用最广的。随着容器云的发展,越来越多的容器运行时涌现。为了 解决这些容器运行时和Kubernetes的集成问题，在Kubernetes 1.5版本中，社区推出了CRI ( Container Runtime Interface,容器运行时接口)以支持更多的容器运行时。 什么是 CRI CRI 是 Kubernetes 定义的一组 gRPC 服务。 kubelet 作为客户端，基于 gRPC 框架，通过 Socket 和容器运行时通信。它包括两类服务: 镜像服务(Image Service)：提供下载、检查和删除镜像的远程程序调用； 运行时服务(Runtime Service)：包含用于管理容器生命周期，以及与容器交互的调用(exec/ attach / port-forward)的远程程序调用。 运行时的层级 容器运行时可以分为高层和低层的运行时： Dockershime，containerd 和 CRI-O 都是遵循 CRI 的容器运行时，我们称之为 高级运行时。 OCI 定义了创建容器的格式和运行时的开源行业标准，包括 镜像规范（Image Specification) 和 容器运行时规范 （runtime specification） 镜像规范定义了 OCI 镜像标准，高层级运行时 将会下载一个 OCI 镜像，并且将它解压为 OCI 运行时文件系统包（file system bundle） 运行时规范描述了如何从 OCI 运行时文件系统包运行容器程序。并且定义它的配置，运行环境和生命周期。如何为新的容器设置命名空间（namespace）和控制组（cgroup) ，以及挂载根文件系统（rootfs）等等操作，都是在这里定义的。它的一个参考实现是 runc，我们称其为 低层级运行时（Low-level Runtime) 高层级运行时(High-level Runtime)：主要包括 Docker,containerd 和 CRI-O 低层级运行时(Low-level Runtime)：包含了 runc, kata,以及 gVisor。 低层运行时 kata 和 gVisor 都还处于小规模落地或者实验阶段，其生态成熟度和使用案例都比较欠缺，所以除非有特殊的需求，否则 runc 几乎是必然的选择。因此在对容器运行时的选择上，主要是聚焦于上层运行时的选择。...

深入理解Kube-APIServer kube-apiserver是Kubernetes最重要的核心组件之一，主要提供以下的功能 提供集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更等 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd） apiserver 主要功能： 认证：使用集群判断身份。 鉴权：使用操作 CRUD，需要权限。 准入： 对于Kubernetes来说，需要一些额外的 actions，例如写入的值不规范，需要对其进行修改，修改后需要 校验。最后需要 限流，以防止恶意或者漏洞导致拥堵 Mutating Validating Admission 限流 APIServer对象的实现 访问控制 API Server 是所有组件交互的 中间枢纽。 Kubernetes API的每个请求都会经过多阶段的访问控制之后才会被接受，这包括认证、授权以及准入控制（Admission Control）等。 前面的是 Mutating Webhook，可以改一个对象的值，而 Validating Webhook 是不可以修改对象的值，不生效的。 更加详细的请求处理流程： 📜 对上面的解释： 如何处理API请求：API源码存在于kubernetes/pkg/api路径中，会处理集群内以及集群外客户端的请求。 那么，当HTTP请求到达Kubernetes API时，具体会发现什么呢？从上层看，会发现以下交互： HTTP请求由一串过滤器（filters）进行处理，这些过滤器注册在DefaultBuildHandlerChain()（参阅源码：https://github.com/kubernetes/apiserver中的config.go）中，并执行相应的处理。过滤器要么会将信息传递并附加到ctx.RequestInfo上（例如通过了身份认证的用户），要么返回适当的HTTP响应代码。 第二步，复用器（multiplexer，参阅源码：https://github.com/kubernetes/apiserver中的container.go）会根据HTTP路径，将HTTP请求路由到相应的处理程序（handler）。 第三步，routes（在routes/*中定义）会将处理程序（handler）与HTTP路径进行连接。 第四步，按照API Group进行注册的处理程序（参阅源码：https://github.com/kubernetes/apiserver中的groupversion.go和installer.go），会处理HTTP请求和上下文（context，如user、rights等），并将请求的对象从存储中传送出来。 注意，为了简洁，在上图中我们省略了HTTP路径中的$NAMESPACE字段。 现在我们进一步深入的对前文中提到的DefaultBuildHandlerChain()中建立的过滤器（filters）进行介绍： **WithRequestInfo()：**在requestinfo.go中定义，将RequestInfo附加到上下文中。...

开始前 ETCD 是 Kubernetes 中所有组件中最难的，因为 ETCD 是有状态的，而不是无状态的。 我在之前做 k3s runtime 设计的时候，了解了一些关于 ETCD 和 Raft 算法相关的概念，作为前奏知识，请分别前往 ETCD 以及 Raft算法 进行前奏学习。 这一篇来深入并且贯穿的讲解 ETCD 和 Raft。并且站在 Kubernetes 的角度来深入 剖析 ETCD。 ETCD 介绍 Etcd是CoreOS基于Raft开发的分布式key-value存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。 包含的功能以及特性 前奏 都有学过，看下 Kubernetes 最关心的 存储： 主要功能 基本的key-value存储 监听机制 key的过期及续约机制，用于监控和服务发现 原子Compare And Swap和Compare And Delete，用于分布式锁和leader选举 使用场景 可以用于键值对存储，应用程序可以读取和写入 etcd 中的数据 etcd 比较多的应用场景是用于服务注册与发现 基于监听机制的分布式异步系统 etcd 是一个键值存储的组件，其他的应用都是基于其键值存储的功能展开。 采用kv型数据存储，一般情况下比关系型数据库快。 支持动态存储(内存)以及静态存储(磁盘)。 分布式存储，可集成为多节点集群。 存储方式，采用类似目录结构。（B+tree） 只有叶子节点才能真正存储数据，相当于文件。 叶子节点的父节点一定是目录，目录不能存储数据。 服务注册与发现：...

介绍 当前模块的执行中，直接传递了众多端口（ws、api、rpc、Prometheus）。 这种方法可能很麻烦，并且不符合 Kubernetes 的最佳实践，即 pod 通常只公开一个端口（80 或 443）。 该提案建议过渡到以配置文件为中心的方法，同时仍然保留在需要时直接传递端口的功能。 目标 简化Kubernetes部署的端口配置。 作为参数传递的端口值优先于配置文件值。 为希望使用传统的基于端口或基于环境变量的部署的用户提供灵活性。 建议的解决方案 1.配置文件 不会直接传递多个端口，而是引入一个配置文件。 默认情况下，该文件将包含预定义的端口。 可以使用 Kubernetes 的“ConfigMap”将该配置文件传递给模块。 配置文件示例： ws_端口：3000 api_端口：3001 rpc_端口：3002 普罗米修斯端口：9090 2. 直接传递端口 虽然 Kubernetes 部署建议使用配置文件方式，但用户仍然可以直接传递端口。 如果端口作为参数传递，这些值将覆盖配置文件中的值。 3.基于环境变量的部署 对于喜欢使用环境变量进行源代码部署的用户，该模块可以设计为读取 Linux 系统上设置为环境变量的端口值。 如果设置了这些环境变量，它们将覆盖配置文件值，但优先级低于直接作为参数传递的端口值。 示例：如果WS_PORT环境变量设置为3005，它将覆盖配置文件中的ws_port值，除非ws_port作为参数传递。 实施步骤 更新模块以读取配置文件：修改模块以从提供的配置文件中读取端口值。 基于参数的覆盖：实现逻辑以覆盖配置文件端口值（如果它们作为参数提供）。 基于环境变量的覆盖：实现逻辑来检查环境变量并使用这些值（如果设置）。 确保直接参数值具有最高优先级。 文档：更新文档以提供有关设置端口值的三种方法的清晰说明：配置文件、直接参数和环境变量。 测试：在不同场景下彻底测试模块： 仅使用配置文件。 将端口作为参数传递。 设置环境变量。 结论 采用配置文件方法可以简化部署过程，尤其是在 Kubernetes 环境中。 虽然配置文件优先考虑简单性，但直接传递端口或使用环境变量的灵活性确保了向后兼容性并满足各种用户偏好。

会议和参考链接 会议参考文档：https://nsddd.notion.site/2899028707604b8090b36677c031cdf8?pvs=4 视频回放：Bilibili: https://www.bilibili.com/video/BV1s8411q7Um/?spm_id_from=333.999.0.0 评论： 那个中间件我觉得可以换成 https://kubeblocks.io 可以帮你管理多个数据库中间件 im 读取配置信息，读取的是 config/ 目录，代码中硬编码补充的 config.yaml，是否可以自动化来对 不同 服务的 rpc 划分，然后统一目录，默认读取的是二进制运行路径的上两层 openim version: https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/version.md 存储可以考虑使用 ： https://github.com/openebs/openebs https://github.com/rook/rook 核心目标： 开源项目和非开源项目的最大的区别，就是一套完整的解决方案。 非开源项目的 集群化部署方案的设计，比较在乎稳定，以及高效，快速，最好一键部署。 开源项目的 集群化部署方案的设计，比较在乎通用性，上手的难度，后期的维护难度，基础架构的稳定性。后面的开发者或者是贡献者，使用者，可以基于此创建自己的集群化部署方案，以及解决方案，并且成为 OpenIM 的集群化部署方案的使用案例。 OpenIM 集群化部署讨论会记录 先总结，后详细解读 ~ 关于开源部署环境的演变与变化 新部署方法：一种集二进制和部署于一体的一键操作。 Kubernetes 部署：在 Kubernetes 环境中实现一键部署的新型方案。 现存问题：涉及日志收集、服务重启追踪等，将在后续对这些问题进行改进并寻求解决方案。 CICD的开发与维护策略 CICD 概念：通过CICD实现Code Streaming。 开发阶段：需要编写出镜像文件。GitHub的CSD功能：已实现但尚待深入研究。 版本标记策略：推荐使用local branch而非直接标签。 关于软件开发与测试的实践经验分享 本地开发：推荐使用“auto-compile”工具快速生成稳定版本的镜像。 团队协作：介绍了各团队间如何协同进行开发、测试和发布。 代码重用：提及将库中的函数或方法封装为组件，实现跨项目调用。 Docker Deployment与Service Configuration 配置传递：主要通过如K8S中的配置文件。 部署方式：介绍了二进制部署和可部署两种策略，并讨论了各自的优缺点。 关于容器化部署和代码优化的探讨 容器化：提议将多个进程合并为一个容器进行管理。 部署方式兼容性：讨论了如何实现并进行微调。 技术架构和组件：如Helm chat、OpenM等，及其在系统中的作用和重要性。 关于一键部署的技术问题与解决方案 一键部署问题：可能的问题有无法翻墙、无法安装等。 解决方案：1) 将现有方案通用化；2) 采用第三方服务实现一键部署。 K8S部署与自动化的优化策略 部署工具：如使用Shell实现一键部署、K ks部署等。 组件整合：考虑如何将不同组件组合成完整解决方案，并保持不同环境中的一致性。 微服务架构中的最佳实践 应用程序部署：建议将应用程序划分为不同的容器，每个容器内运行一个业务进程。 代码整合：提议将相关代码整合为一个文件进行管理。 微服务的优化与部署策略 微服务划分：强调避免过于细致的模块分割。 自动化：部署时不增加额外维护工作量，采用自动化策略。 关于存储方式和编排工具的选择 文件存储：如使用NFS作为本地分布式文件存储。 编排工具：推荐使用 rook 进行对象存储编排，数据库使用专用编排器。 NFS与Flexible File System的应用 苹果手机上的MFS：讨论了其使用情况和如何同步全局配置文件到各业务模块。 PV/PVC管理数据：示例讲解如何使用此文件系统进行数据管理。 二进制代码与配置文件的应用 代码适配：通过配置文件进行，涉及传递配置路径、文件映射等细节。 关于软件开发中的优化与改进 项目脚本编写：讨论了性能瓶颈、部署统一处理、服务发现模块的优化建议。 关于Web应用配置文件的编写与优化 IP分配：配置文件用于IP分配和模块间分段处理。 接口应用：如在不同环境使用不同的接口实现心跳等功能。 技术架构改进：优化轻量化、提高开发效率和维护效果等。 结论：本次讨论会涉及了开源部署环境的多个方面，从软件开发、部署、测试到微服务架构和存储方式等多个领域。希望通过此次讨论，可以为OpenIM的集群化部署提供有力的参考和指导。...

why? 故事是从这个 proposal 开始idea~ 🤖 OpenIM cicd robot machine proposal Prow是基于Kubernetes的CI/CD系统。作业可以由各种类型的事件触发，并将其状态报告给许多不同的服务。除了作业执行，Prow还以策略执行、通过 /foo 风格命令的聊天操作和自动PR合并的形式提供GitHub自动化。 有关 Golang 文档，请参阅 GoDoc。请注意，这些库仅供prow使用，我们不会尝试保留向后兼容性。 Kubernetes 专门为 Prow 提供了网页命令查询： https://prow.k8s.io/command-help 关于Prow如何运行作业的简要概述，请参阅 Prow作业的生命周期。 要查看Prow的常用用法和交互流，请参见拉取请求交互序列图。 hello world 最简单的一个上手案例莫过于 pull request 。 提出一个拉取请求（以下简称PR）。在PR正文中，可以随意添加区域标签（如果合适），例如 /area <AREA> 。标签列表在这里。也可以随意推荐一位评论者 /assign @theirname 。 一旦你的审阅者满意，他们会说 /lgtm ，这将应用 lgtm 标签，如果他们是OWNER，将应用 approved 标签。 approved 标签也将自动应用于所有者打开的PR。如果你和你的审阅者都不是OWNER，请 /assign 某个所有者。如果你的PR有 lgtm 和 approved 标签，没有任何 do-not-merge/* 标签，并且所有测试均通过，则PR将自动合并。 查看测试结果 Kubernetes TestGrid 显示历史测试结果 在 testgrid/config.yaml 配置自己的 testgrid 仪表盘 Gubernator 格式化每次运行的输出 PR Dashboard 查找需要注意的 PR Prow 安排测试并更新问题 Prow 响应 GitHub 事件、定时器和在 GitHub 评论中给出的手动命令。 prow dashboard 显示当前正在测试什么 在 config/jobs 配置 prow 运行新测试 Triage Dashboard 汇总故障 将故障集群在一起 搜索跨作业的测试失败 在特定的测试和/或作业的 regex 中过滤失败 Velodrome 指标跟踪作业和测试健康状况。 Kettle 进行收集，metrics 进行报告，velodrome 是前端。 功能和特性 prow 的功能很强大，甚至是比 actions 更加出众。可以测试、批处理、工件发布的作业执行。...

准备 这篇文章等的太久了，大致 四个月了把，也是自己经历 docker 跨越到 Kubernetes 以及 CloudNative 生态的过程。 反过来再去理解开源、理解 sealos、 理解 Kubernetes，有种豁然开朗的视角。 这篇文章和其他文章不一样的是，这篇是按照自己现在的思路来写的，具体为什么，在以前的文章中能找到答案~ 从 CMD 角度上对接源码，从最开始出发： 不管是 sealer 还是 sealctl，都离不开 镜像的构建核心》 buildah： package main import ( "github.com/containers/buildah" "github.com/labring/sealos/cmd/sealctl/cmd" ) func main() { if buildah.InitReexec() { return } cmd.Execute() } 从 InitReexec 调用 buildah 初始化开始，进行走进 sealos 的大门：Execute 在 cobra 中，Execute 只会执行一次，不管是正确的还是失败的~ 在调用的时候，会先执行 init 初始化函数，它 定义了一些初始化工作以及标志： func init() { cobra.OnInitialize(func() { logger.CfgConsoleLogger(debug, showPath) }) rootCmd.PersistentFlags().BoolVar(&debug, "debug", false, "enable debug logger") rootCmd.PersistentFlags().BoolVar(&showPath, "show-path", false, "enable show code path") } 哈哈，sealos 对于日志包的封装，还是很让我惊喜的，使用了 zap 进行二次开发和封装，用于适合自己的业务需要，这对我是有参考意义的，包括 horizon，未来可能需要在 日志包和 错误码设计上进行改进，这是成就一个优秀的开源项目的必要条件~...