Development

关于我 #最后的大学生涯 #旅行见闻 #跨国冒险 #生活转变 #成长故事 #探索未知 #回忆录 #文化体验 #自然之美 #城市漫步 #历史沉淀 #户外探险 #山川露营 #人生第一次 #世界遗产 #美食体验 #生活与工作的平衡 #毕业倒计时 #从武汉到深圳 #安徽黄山 #歙县古城探秘 #丽江古城之旅 #江西武功山探险 #香港麦理浩径 #澳门巴黎人游历 #川西雪山震撼 #马来西亚独旅 #新加坡探索 不知不觉间，这一年悄然流逝，时间仿佛在指尖间轻轻滑过，我也迎来了大学生活的最后一年。就在刚刚，我还仿佛站在武汉江汉路的大钟下漫步，感受着城市的脉动与历史的沉淀。转眼之间，我已经来到了深圳，这座我生活了大半年的城市。一切变化都显得如此迅速，却又自然而然，生活在这里，我感受到了不同的节奏和氛围。 旅行已然成为自己的生活和工作的平衡点，这一年，去过无数个地方，去过安徽黄山，还去过周边的 歙县古城 歙县古城和丽江古城。第一次重装去江西武功山；第一次去绝美的香港麦理浩径，也在香港尝试了第一次绝好的露营体验；第一次去繁华的澳门，看了看澳门巴黎人。第一次去梦想中的川西，看到了让我震撼，触我心弦的雪山。也在第一次一个人出国马来西亚，一个人去新加坡 …. ，这篇博客来记录和回顾这一年来的经历，所见，所想 ~ 去年三月，第一个和室友 刘洋 ，鼓起勇气迈出大学的第一站， 黄山 。 人生第一次爬山 | 黄山 黄山旅程 ~ #第一次爬山是什么感受 黄山 古城 黄山有多美？ 印象中记不清了，大脑中的杏仁核还是触发海马体进行了记忆检索，触动到了那天晚上登高，抬头望月，满眼云海的景象，平静的夜晚同时自己的荷尔蒙飙升到两百。这是我第一次抱着非常非常节省的心态去的旅行，黄山下有缆车，可以直达迎客松，但是我当时想着省钱就没上了，我觉得这是第一次的经验缺乏的不足。前期不断地爬山爬山 … ，心想，不愧是五大名山，这么难爬，这辈子第一次爬这么高的山，实际山艰难的是。每爬山去一座山，后面依旧有一座佁然不动的大山阻在你前方，仿佛一颗千斤重的石锤压在你的内心，压得呼吸混乱，心乱如麻。 我们的冒险之旅从下午开始，直至晚上六点才踏上攀登的征途。沿途我们努力攀爬，终于在黄昏时分隐约见到了令人叹为观止的云海，这可能是我人生中第一次近距离观赏如此绝美的景象。到达山顶时，索道已经停止运营，让我们在凉爽的山风中驻足片刻，然后开始了夜间的下山之旅。不同于白天的紧张气氛，夜晚的山路带来了一种宁静而神秘的体验，下山后我们赶紧找一家酒店就住下了 ~ 晚上还在计划第二天继续完成第一天没有爬完的任务 ~ 但是第二条腿好疼，选择换一个地点旅游 。 随后我们前往黄山周边的小镇继续我们的冒险。比如，宏村或西递，这些小镇以其保存完好的古建筑和充满江南水乡特色的景观而闻名。恰逢阴天，小镇的氛围显得尤为迷人，雨后的青石板路，古老的徽派建筑，以及悠然自得的生活场景，构成了一幅动人的画面，拍照时更是别具一格，充满了江南水乡的独特韵味和艺术感。 感触 在这次旅途中，我意识到自己的准备工作并不充分，但路途中遇到的每一位旅人、每一次经历都给我留下了深刻的印象。当我第一次目睹云海的壮观景象时，心中的激动难以言表。夜晚的月光与宁静的环境相结合，呈现出一种难以捉摸的美，是我此前未曾体验过的意境。 第一次踏足江南小镇，那里的美景让我流连忘返。街道美丽异常，小桥流水人家，恰如其分地展示了江南水乡的独特魅力和古朴风情。这不仅是一次对身体的锻炼，更是一次精神上的洗礼。攀登高山，俯瞰云海，仰视密集或稀疏的村落，这些体验让我感受到了自然的壮丽和生活的多样性。 回顾自己走过的每一步，或许是平平淡淡也好，艰难险阻，枯燥乏味，还是万紫千红也罢，总归是自己踏踏实实走过来的，总归是自己一步步感受和思考过来的。 来来往往的爬山者很多，人们为了不同的追求而爬山，或锻炼，或释压，或赏玩，都无所谓，重点是你去做了，他去做了，我们去做了。 于是，黄山教会了我第一课：勇敢迈出第一步，不要恐惧陌生感，勇敢出去看看 ！...

深入理解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 的特殊支援不再有意義。...