Kubernetes 控制平面 - Kubectl

Kubelet组件解析 理解 kubelet Kubelet组件运行在Node节点上,维持运行中的Pods以及提供kuberntes运行时环境,主要完成以下使命: 1.监视分配给该Node节点的pods 2.挂载pod所需要的volumes 3.下载pod的secret 4.通过docker/rkt来运行pod中的容器 5.周期的执行pod中为容器定义的liveness探针 6.上报pod的状态给系统的其他组件 7.上报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 架构如下图所示:...

September 28, 2023 · 2 分钟 · 421 字 · Xinwei Xiong, Me

Kubernetes 控制平面 - 调度器

调度器 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....

September 28, 2023 · 4 分钟 · 668 字 · Xinwei Xiong, Me

Kubernetes 的 CNI,CRI,CSI 详解

容器运行时 容器运行时(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 几乎是必然的选择。因此在对容器运行时的选择上,主要是聚焦于上层运行时的选择。...

September 28, 2023 · 11 分钟 · 2200 字 · Xinwei Xiong, Me

深入了解Kubernetes Kube apisserver的组件

深入理解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附加到上下文中。...

September 28, 2023 · 7 分钟 · 1326 字 · Xinwei Xiong, Me

深入了解Kubernetes等组件之ETCD

开始前 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) 只有叶子节点才能真正存储数据,相当于文件。 叶子节点的父节点一定是目录,目录不能存储数据。 服务注册与发现:...

September 26, 2023 · 6 分钟 · 1264 字 · Xinwei Xiong, Me

OpenIM 的集群化设计 | 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的集群化部署提供有力的参考和指导。...

September 17, 2023 · 2 分钟 · 342 字 · 熊鑫伟, Me

Kubernetes一篇快速入门的文章

正片开始~ Kubernetes 是 Google 团队发起的一个开源项目,它的目标是管理跨多个主机的容器,用于自动部署、扩展和管理容器化的应用程序,主要实现语言为 Go 语言。Kubernetes 的组件和架构还是相对较复杂的。要慢慢学习~ 我们急需编排一个容器~ 为什么 kubernetes 弃用了 docker ::: tip 很意外 听到 Kubernetes 从 Kubernetes 版本 1.20 开始弃用对 Docker 作为容器运行时的支持,这似乎有点令人震惊。 Kubernetes 正在删除对 Docker 作为容器运行时的支持。Kubernetes 实际上并不处理在机器上运行容器的过程。相反,它依赖于另一个称为容器运行时的软件。. ::: docker 比 kubernetes 发行的早 docker本身不兼容 CRI 接口。Kubernetes 适用于所有实现称为容器运行时接口 (CRI) 标准的容器运行时。这本质上是 Kubernetes 和容器运行时之间通信的标准方式,任何支持此标准的运行时都会自动与 Kubernetes 配合使用。 Docker 不实现容器运行时接口 (CRI)。过去,容器运行时没有那么多好的选择,Kubernetes 实现了 Docker shim,这是一个额外的层,用作 Kubernetes 和 Docker 之间的接口。然而,现在有很多运行时可以实现 CRI,Kubernetes 维护对 Docker 的特殊支持不再有意义。 ::: warning 弃用的意义 虽然移除了 docker ,但是还是保留了以前的 dockershim,如果你愿意,你依旧可以使用 docker 容器化引擎提供容器化支持。...

April 28, 2022 · 3 分钟 · 504 字 · Xinwei Xiong, Me