blog

深入理解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） 只有叶子节点才能真正存储数据，相当于文件。 叶子节点的父节点一定是目录，目录不能存储数据。 服务注册与发现：...

自動化構建openkf的多架構鏡像並推送到多個鏡像倉庫 https://github.com/openimsdk/openkf 描述： 為了滿足各種用戶的需求，我們的目標是自動化構建用於各種架構的openkf Docker鏡像，並無縫地將它們推送到多個鏡像倉庫。 目標： 自動構建openkf的linux/amd64和linux/arm64架構的Docker鏡像。 將鏡像推送到Docker Hub、阿里雲Docker Hub和GitHub容器倉庫。 任務： 設置多架構構建系統 使用GitHub Actions，配合QEMU和Docker Buildx，支持linux/amd64和linux/arm64的多架構構建。 在每次新版本發布、提交到main分支或定期事件時，觸發構建過程。 支持多個鏡像倉庫 Docker Hub：推送到openim/openkf-server。 阿里雲Docker Hub：推送到registry.cn-hangzhou.aliyuncs.com/openimsdk/openkf-server。 GitHub容器倉庫：推送到ghcr.io/openimsdk/openkf-server。 動態鏡像標記 使用Docker Metadata Action，基於事件（如定期觸發器、分支提交、拉取請求、語義版本控制和提交SHA）生成動態標籤。 確保在拉取請求事件中不推送已構建的鏡像。 身份驗證和安全性 使用秘密配置Docker Hub、阿里雲和GitHub容器倉庫的身份驗證。 確保每個倉庫的推送操作都是安全且無縫的。 通知和日誌 通過GitHub Actions，如果有任何構建或推送失敗，向開發團隊發送通知。 保留每次構建和推送操作的日誌以供追踪。 驗收標準： openkf鏡像應該成功地為linux/amd64和linux/arm64架構構建。 在成功構建後，鏡像應該在Docker Hub、阿里雲Docker Hub和GitHub容器倉庫上可用。 根據定義的事件和屬性正確標記鏡像。 整個過程中不需要人工干預。 附加說明： 自動化過程在GitHub Actions工作流中定義。確保根據需要查看和更新工作流。 確保在單獨的分支或環境中測試此過程，以避免中斷。

你好，我是熊鑫偉 在光陰的長河中，我如此榮幸地踏入大四的這個重要時刻。不僅僅是一位學生，我熱衷於編寫那些跳動的代碼，於是，我成為了開源的狂熱追隨者。歡迎你探索我的數字天地——我的GitHub。這裡，你將看到我對技術的熱愛，我的第三代博客，我期待它能成為我與這個世界對話的終極紐帶。 在無數社區中，OpenIM 如同閃耀的北極星，引領我前行，灌溉我的技術之心，讓我真實地行動起來。 然而，我的生命並非僅停留在屏幕前。 從此，世界不再是書本，而是展開在我腳下的廣闊天地。戶外的召喚使我欣喜，無論是我獨自的冒險還是與朋友的歡聚，每一個步伐都是對自然的敬意和生命的探索。 我尋找開源的深意，並在閱讀中不斷地得到啟示： 《開源的成功之路》：它讓我明白，每一個成功都不是偶然，而是走過的那些佈滿荊棘的道路的回報。 《大教堂與集市》：開源並不僅僅是代碼的分享，它更是心與心的交流，是一種對自由與創新的追求。 《黑客與畫家》：這部作品是我至今的最愛，它提醒我，真正的價值不在於你擁有了什麼，而在於你創造了什麼。 > “你的價值取決於你創造了什麼，而不是你擁有什麼。" 這句話是我每日的座右銘，激勵我持續前行，創造屬於自己的美好。 開源，於我，是一個旅程，充滿了未知與挑戰。但我渴望在這條路上遇到更多的同路人，與你共同分享，共同創造。 我真心邀請你，與我一起，探索這個充滿可能的世界。

正片開始~ 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 的特殊支援不再有意義。...