Blog

今天学习 rust ，发现 rust 是非常适合编写数据库的语言，找到了一个宝藏的项目 tikv，它的 github 项目地址是 https://github.com/tikv/tikv ，是一个非常活跃的项目，但是我今天的主题是 AI 领域的向量数据库，话不多说，我们马上开始吧。 先决条件 0.1 基础知识介绍：了解向量数据库的基本定义及其与传统数据库的区别。 0.2 数据结构基础：学习向量和其他基本数据结构，如何在数据库中表示和操作这些结构。 0.3 线性代数入门：介绍向量运算，包括向量加法、减法和点乘。 0.4 相似性度量：了解如何计算向量间的相似度，例如余弦相似性。 0.5 数据库索引基础：介绍数据库索引的基本概念，特别是在向量数据库中的应用。 0.6 搜索算法初步：学习基础的搜索算法，理解如何在大型数据集中进行有效的搜索。 0.7 应用案例研究：研究向量数据库在不同领域（如推荐系统、图像识别）中的应用。 主要课程 1.1 向量数据库深入：探索向量数据库的高级特性和优势。 1.2 算法探究：深入了解在向量数据库中使用的关键算法，包括索引和搜索算法。 1.3 数据库设计：学习如何设计和实现一个有效的向量数据库架构。 1.4 集成机器学习：了解如何将向量数据库与机器学习模型集成，以提高性能和功能。 1.5 实际案例分析：通过分析实际案例来加深对向量数据库应用的理解。 1.6 高级数学概念：深入学习相关的高级数学概念，如高维空间的向量表示和操作。 1.7 项目实践：开展一个小型项目，实践向量数据库的设计和应用。 1.8 回顾和评估：复习所学内容，并通过评估来测试理解和应用。 0.1 基础知识介绍 向量数据库是一种特殊类型的数据库，它们使用数学向量来表示和存储数据。这与传统数据库有很大的不同，传统数据库通常使用表格和行来组织数据。 向量数据库的定义 💡 向量数据库是如何工作的？ 在向量数据库中，数据以向量的形式进行存储和处理，因此需要将原始的非向量型数据转化为向量表示。数据向量化是指将非向量型的数据转换为向量形式的过程。通过数据向量化，实现了在向量数据库中进行高效的相似性计算和查询。此外，向量数据库使用不同的检索算法来加速向量相似性搜索，如 KD-Tree、 VP-Tree、 LSH 以及 倒排索引 等。在实际应用中，需要根据具体场景进行算法的选择和参数的调优，具体选择哪种算法取决于数据集的特征、数据量和查询需求，以及对搜索准确性和效率的要求。 它们是如何使用向量来存储和处理数据的？ 向量数据库使用数学向量来存储和处理数据，这与传统的数据库存储方式有显著不同。这里的关键步骤和概念包括： 数据转换为向量 🔄 在向量数据库中，数据首先被转换为数学向量的形式。例如，文本数据可以通过自然语言处理技术转换为向量，图像数据可以通过深度学习模型转化为向量。 向量表示 📈 每个数据项都被表示为一个向量，这个向量在多维空间中有其特定的位置和方向。这些向量通常在高维空间中，每个维度代表数据的一个特征。 相似性搜索 🔍 向量数据库的一个关键功能是相似性搜索。它通过比较数据项的向量之间的距离（例如，使用余弦相似性）来找到相似的项。这对于处理复杂查询和大数据集特别有效。 索引和检索 📚 向量数据库使用高效的索引机制来快速检索和访问数据。这些索引帮助数据库快速定位查询中涉及的向量，从而加快搜索速度。 机器学习集成 🤖 许多向量数据库可以与机器学习模型紧密集成。这允许数据库不仅存储数据，还可以通过模型直接处理和分析数据，从而提供更高级的数据处理和分析能力。 通过使用向量来表示和处理数据，向量数据库能够处理更复杂、更丰富的数据类型，同时提供更快的搜索和检索性能。这使它们在如今的数据驱动世界中变得越来越重要。 ...

OpenIM 构建高效的版本控制和测试流程 开源项目的成功与否在很大程度上取决于其质量管理和协作流程。在 OpenIM 开源社区中，项目管理和测试流程的规范性至关重要，以确保代码的质量和稳定性。本文将简要介绍我们的测试方案、分支管理和质量控制策略，以及如何应用于 main 分支、PR 测试分支和稳定的 release 分支，以满足开发者、测试人员和社区管理者的需求。除此之外，还将介绍OpenIM开源社区的规范、测试方案和项目管理策略，旨在提供清晰的指导，以确保项目的稳定性和可持续性。 分支管理与版本控制 对于 OpenIM 来说分支的版本管理策略是尤其重要的，这里面设计到两块，一块是 OpenIM 的部署分支策略，一个是镜像版本策略，这两块分别参考下面的文章： 分支以及 tag 的版本策略 镜像的版本策略 总的来说： 在OpenIM社区中，main 分支被视为稳定版本的代表。所有代码必须经过严格的代码审查和测试，确保其质量和稳定性，然后才能合并到 main 分支中。 release 分支用于发布稳定版本。在 openim-docker 以及 openim-k8s 中使用的镜像版本也都是 release-v3.* 。在 release 分支上的任何更改都应该是针对已知问题的修复或功能的精心策划的添加。测试工作应重点关注于 release 分支，以确保发布版本的可靠性。 测试方案 Main 分支测试 在 main 分支上进行的测试应覆盖核心功能和关键路径，以确保基本功能的稳定性。测试工作应包括单元测试、集成测试和端到端测试。这部分所有的工作全部交给自动化去做，而不需要测试干预。 Release 分支测试 对于三种仓库，分别是 https://github.com/openimsdk/open-im-server 仓库，https://github.com/openimsdk/chat 仓库，https://github.com/openimsdk/openim-sdk-core 仓库。 在 release 分支上进行的测试要求更严格。测试团队应深入测试所有功能，并着重检查先前已知的问题是否已解决。确保在发布前没有潜在的问题。 这里的 PR 合并规则： 以 这个PR 为例： 首先是 PR 标题，PR 标题 fix pageFindUser ，首先，我们知道 git commit 信息包括是三种： ...

2024年1月6日大语言模型分享会 模型的局限： 深度学习 预训练模型 大语言模型 大语言模型的涌现能力： 💡 复杂系统学科里已经对涌现现象做过很久的相关研究。那么，什么是“涌现现象”？当一个复杂系统由很多微小个体构成，这些微小个体凑到一起，相互作用，当数量足够多时，在宏观层面上展现出微观个体无法解释的特殊现象，就可以称之为“涌现现象” Link: 大语言模型进化之谜：涌现现象的挑战与争议_AI_张俊林_InfoQ精选文章 大语言模型的特点趋势的转变： 大语言比人更懂人类的习惯。 使用 RLHF 训练 使用人类习惯的方式交互 大语言模型的发展脉络： 开源模型越来越多，比例越来越大。 预训练模型依旧是非常多的，但是微调的比例越来越高 如何学习大语言模型 模型结构的配置 大语言模型的微调 使用技巧 自己训练模型 不一定要只是单一的数据，也可以是数据的混合（包括自己提供的业务文档或者代码） 训练的数据来源： 💡 数据安全和重复数据的去重，数据筛选很重要（这一步该怎么做？） 当处理和准备用于机器学习模型训练的数据时，确保数据的质量、安全性、和去重非常重要。这里有一些关键步骤和方法，可以帮助你实现这一目标： 质量过滤（Quality Filtering）: 确保数据准确无误：移除或修正任何错误的、不完整的或者是不准确的数据。 保证数据的一致性：确保所有的数据遵循同样的格式和标准。 数据去重（Data Deduplication）: 识别和移除重复数据：使用算法或者工具来识别完全相同或高度相似的数据项，并将其合并或删除。 对于文本数据，可以使用哈希算法或者基于内容的去重方法。 隐私去除（Privacy Removal）: 确保数据中不含有任何个人可识别信息（PII），如姓名、地址、电话号码等。 在某些情况下，可以使用数据脱敏技术，如匿名化或伪匿名化，来保护用户隐私。 分词（Tokenization）: 对于文本数据，分词是将连续文本分割成更小单元（如单词、短语或字符）的过程。 分词的方法依赖于特定语言的语法和词汇结构。对于中文，可能需要特定的分词工具，因为中文是一个无空格分隔的语言。 解码器结构 “causal decoder"和"prefix decoder"是两种不同的解码器结构，它们在处理序列数据，尤其是在文本生成任务中扮演着重要角色。下面是这两种解码器的对比： Causal Decoder (因果解码器) 定义和应用: 因果解码器，如在GPT系列模型中所使用的，是一种单向解码器。 它在生成文本时，仅考虑已经生成的或给定的前文（即，它只看到左侧的上下文）。 工作原理: 在处理每个新词时，因果解码器仅使用前面的词作为上下文。 这种模式模拟了人类自然语言的生成方式，即基于已知信息顺序地产生新信息。 用途: 适用于文本生成任务，如故事叙述、自动写作、聊天机器人等。 特点: 保证了生成的文本是连贯的，并且在逻辑上遵循了之前的上下文。 不能回看或考虑未来的词汇或句子结构。 Prefix Decoder (前缀解码器) 定义和应用: 前缀解码器是一种可以同时考虑前文和后文的解码器，类似于BERT中的masked language model（MLM）。 它在处理数据时，可以同时考虑序列中的前缀和后缀信息。 工作原理: 在处理每个词时，前缀解码器使用前面的词和后面的一些占位符或掩码作为上下文。 这种方式使得解码器在生成某个词时，可以考虑到整个序列的结构。 用途: 常用于需要双向上下文理解的任务，如文本填空、句子完善、语言模型训练等。 特点: 能够在生成文本时考虑到更全面的上下文信息。 更适合于理解整个句子或段落的结构和含义。 模型结构的优化 模型结构优化一直以来都是比较fancy的工作，优秀的模型结构设计，可以大大提高模型参数的效率，甚至小模型效果可以超过大模型。本文我们以XLNet、ALBERT、ELECTRA为例进行分析。虽然他们也可以认为是预训练任务优化和模型轻量化方面的工作，但鉴于模型结构创新力度很大，我们还是在模型结构优化这个版块来分析他们。 ...

我的 2023 年度总结 2023 很快就要过去了，转眼间大学生活只剩下最后半年了，我一个朋友说过，工作的越久越是觉得：*可怕的不是你失去了工作的激情，而是再也找不回来了。* 这一年经历了很多，接触了很多人，遇到过很多事情，慢慢的对自己的三观有种雏形。很喜欢马斯洛需求层次理论(Maslow’s hierarchy of needs) 从中找到自己的状态。我喜欢挑战，无论是工作还是业余爱好（爬山，骑车 …）我似乎已经成功地满足了马斯洛需求层次理论中的前四个级别：生理需求、安全需求、社交需求和尊重需求。我目前所处的阶段很可能是自我实现需求。但是值得一提的是，虽然马斯洛的理论是分层的，但实际上人的需求可能不会那么线性或固定。例如，即使一个人达到了自我实现的阶段，他们仍可能在不同时间遇到其他层次的需求。例如，如果一个人失去了工作或遭遇经济困难，他们可能会重新关注安全需求，比如财务安全和稳定。同样，如果一个人经历了亲密关系的结束或社交网络的变化，他们可能会重新感受到对社交需求的渴望。甚至在日常生活中，像是在生病或饥饿时，我们的注意力可能会暂时从更高层次的需求，如自我实现，转移到生理需求上。 我认为我们应该认识到，虽然人们可能在不同时间点上侧重于不同的需求层次，但这并不意味着他们在个人发展上有所倒退。相反，这是一个自然的、动态的过程，反映了人生的复杂性和多变性。在面对挑战和变化时，能够灵活地调整自己的需求焦点，是适应和个人成长的一部分。所以，顺其自然，把握节奏，不断学习，不断思考，是我的成长生存名言。 户外很大一个程度上，放松了我的思想，让我能站在一个局外的角度看待整个棋局。纵穿整个成长的周期，我们就像是深处在一个棋局上，每一个角色都不可或缺，但却都有自己的局限性。 今年有一种冲劲，很讨厌温水煮青蛙的生活，以及安于现状的人生，偶尔出现一点点的 idea，或者是灵光一闪，偶然间有一个冲动想自己创业做下去。这些想法也被我一点点的记录在本子上，我总觉得以后可能有机会会翻起，那时候会孤注一掷的去做。处在马斯洛的自我实现需求的层级上，渴望做出自己的事业。事业和工作，事业指人们所从事的具有一定目标，规模和系统的对社会发展有影响的经常活动；而工作指在长时间内做着重复的一系列动作或事情。很明显，我们都知道，如果人生是一个游戏，那么后者的角色就是一个 NPC，做的永远都是重复，没有任何价值的增效的工作，不利于个人成长，对社会的进步也是微乎其微。做事业和做生意也是有所区别的，生意是以短期赚钱为导向，事业是以人生高度为导向。 在重庆游玩的时候，也是和一个非常厉害的创业前辈交流过（经历和认知，文化水平卓越），明白了，对于以赚钱为驱动，那么就是在做生意；如果是以梦想，热爱，坚持为驱动，那么就是真正的做事业，赚钱，只是这个过程中的水到渠成。作为一个螺丝钉，在一线上工作，尽管象棋中的兵看似不起眼，但它们是实现战略目标的基础。在创业中，前线员工（开发、测试、运维）和日常运营团队就像这些兵，他们执行日常任务，是企业运行的基石。但是，如果只是做士兵，那么当然可以安于现状，但是，如果你期望做出自己的事业来，那么当然是不够的，只专注于日常的业务操作而没有更广阔的视野，可能会错失重要的战略机会。你还需要跳跃出你的思维和格局，要结合象的远见、马的创新思维和车的执行力。这意味着你需要能够制定长远的战略规划（象）、灵活地应对突发情况并创造性地解决问题（马），以及直接推动业务前进（车）。甚至是要有战略性思维，如果是作为企业的战略领导者，类似于象棋中的国王。具备全局视角，设定公司的长远目标和战略方向。虽然国王在棋盘上的移动有限，但却是游戏的核心。同样，作为创业者，我们可能不会直接参与每一个细节，但是，作为决策者的的决策和愿景对公司至关重要。从此，无论是工作中还是项目中，我常常是将自己带入到棋盘中的各个角色，去认真感受棋局以及每个角色的变化。 在职业生涯中，遇到面试官反问的环节，我比较喜欢询问的几句话： 在您看来，员工为什么选择留在这家公司？他们对工作最热情的方面是什么？ 您为什么要选择这家公司，您个人在这里工作的最大动力是什么？您认为同事们最看重公司的哪些方面？ 您能描述一下这里的工作环境吗？员工通常是怎样描述他们在这里的工作体验的？ 您作为老板，能告诉我您的创业经历吗，为什么要选择创业，创业意味着什么? 您能分享一下公司领导的领导风格吗？他们是如何激励团队和推动创新的？ 这些问题潜在的可以帮助你了解员工和老板的工作状态，思想。 在中国传统教育框架体系中，成功的定义是，拥有自己的事业。当然在课本上也并非如此，成功其实是一种感觉，可以说是一种积极的感觉，它是每个人达到自己理想之后一种自信的状态和一种满足的感觉！总之，我们每个人对于成功的定义是各不相同的！在简易的成功学中，成功的定义是：*天赋，努力和运气* 。用我们平常 code 的思维理解，三者中或只有 努力 是可以读写操作的，而天赋和运气都是可读的，但并不能写操作。所以，对于我们大部分普通的人来说，都是 “尽人事，听天命” 的状态。记得有首励志的歌这么说的：你尽管努力，剩下的交给天意 。 于是，这就是今年形成的思想，勇敢的去做，不要怕失去，努力也是一种投资，就像二级市场的 K 线图一样，有涨有跌。拿三种曲线举例，第一条曲线前期曲曲折折，突然在一个转折点扶摇而上，直冲云霄；第二条曲线前期曲曲折折，后期也是曲曲折折，不上不下；第三条曲线前期也是曲曲折折，突然一个转折点暴跌，坠入低谷；我们大部分人都渴望走第一条曲线的道路，但是，前期的曲曲折折，是否会迎来某一个转折点，没有人知道。有时候我们可能会感到停滞不前，甚至是跌宕起伏，但这并不意味着失败。稳定可以是成长和自我反思的机会，也可能是积蓄能量、准备下一次跳跃的阶段。勇敢地面对挑战，不惧怕失去，将努力视为一种投资，是通向成长和成功的关键。生活和职业道路有其起伏，这些在儒家思想中可见，对待得与失、荣与辱、成与败等等，乃至人生的吉凶祸福，人们应注重“求诸己”，不假外力，更不应怨天尤人。重要的是如何应对这些起伏，以及我们从这个过程中学到了什么。 接下来以下面的几个议题快速的对自己做年度总结: 首先，专业上，最具有代表性的是我的专业名片，github 地址 Github 的贡献的小绿点： 我的 gihtub 2023 徽章： 一、开源项目贡献 以 github 代表为例，今年的 ossinsight 表现： 项目参与： 2023 年主要参与的开源项目: openim , 参加了阿里的开源项目 sealer ，网易的 gitops 项目 horizon ，贡献了 kubernetes 项目、k8sgpt 。提出了基于 AI和大语言模型的智能客服 openkf …… 技术成长： ...

引言：深圳福田会展中心的全球视野 2023年12月6日，在深圳福田会展中心，GTC 2023 全球流量大会如火如荼地展开。这场盛会汇集了来自全球的技术精英，共同探索互联网行业的前沿动态和未来发展趋势。身为参与者，我有幸深入这场融合科技与商业的交流盛会，特别是“聚焦开源，扩展出海新领航”这一议题，让我收获颇丰，印象深刻。 大会聚焦于全球化的多元话题，包括出海市场的选择、广告推广策略等，与我此前参加的专注于日本市场出海活动的公司非常相似。然而，这次大会让我首次深入接触开源社区，不仅结识了众多开源界的领袖和布道者，也与许多杰出的开发者交流了心得。通过这些交流，我不仅学习到了许多新知识，还在思想上得到了升华。 在这篇博客中，我将对这次独特的经历进行深入的反思和总结，分享我在开源和全球化交汇中的洞见和学习。 对于 OpenIM 来说，我们现阶段正在全力准备奔向海外市场，希望打开国界，将 OpenIM 好用而且免费的开源核心功能贡献给全世界开发者。 开源项目天生就是分布式协作的，这是一种松散的结构。以 OpenIM 的开发者为例，我们现在有很多贡献者，开发者，虽然社区有双周会，但是还是很难和人或者同事有深层次的交流。 但对于开源商业公司而言，并不能简单的使用这种远程工作模式。在商业公司中，协作会更加的密切，而且对时效性的要求更高，当面沟通更能保证信息传递的完整性，这是远程工作难以替代的。当然，远程工作也有自己的优势，那就是吸引全球的人才。 所以，开源商业公司采用远程协作并没有问题，但一定要保证沟通的足够充分，拉平信息： 要视频沟通，文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式，是远程工作交流的首选方式。千万不要用文字来讨论非技术问题，这会带来巨大的信息差和误解。 保证沟通的尊重和善意。在开源项目中，大家因为没有雇佣关系，都是无偿做贡献，所以在异步沟通时特别强调尊重和善意；而在商业公司的远程办公时，因为缺少同事之间的沟通、吐槽和心理按摩，就更要注意沟通的尊重。 定期线下见面，增加相互之间的了解和信任。 另外一点，长期的远程协作，对于参与的工程师来说，除了需要很高的自律和自我管理的要求外，也要注意工作和生活的隔离，保持正常的社交活动和运动健身，否则很容易与社会脱节。 之前和 Apache APISIX 的某个小姐姐聊天，她说的一句话感触很深。也有很多适应不了远程工作的同事一一离去，这也是一个适者生存的达尔文法则。 关于 OpenIM 的远程工作，以及企业的文化，强烈推荐阅读下面的博客： Englist Version 中文版本 出海挑战：中国互联网企业的全球化之旅 中国互联网企业在全球化道路上的探索充满挑战与机遇。从初涉海外市场的尝试到在竞争激烈的国际环境中求生存，它们不断在新的市场环境中寻找增长点。这一过程中，企业需要超越传统的商业模式，适应多元文化和不同的市场需求。 首先，来到了第一个话题，为什么要去做海外社区？ 和很多的开源社区的布道者和专家沟通交流，然后反思，我深信建立一个活跃的海外社区是开源项目成功的关键。在全球化的今天，开源不仅是关于代码的分享，更是一种文化和思想的交流。通过建立海外社区，我们不仅能将技术带到世界的每个角落，还能促进不同文化背景下的思想碰撞和创新。 人性化地讲，建立海外社区意味着建立更广泛的连接和共鸣。每一位开源贡献者，不论身处何地，都希望他们的声音被听见，他们的贡献被认可。海外社区提供了一个平台，让来自世界各地的开发者能够参与到项目中来，分享他们独特的视角和经验。这种多元化的参与不仅丰富了项目本身，还激发了更多创新的火花。 同时，海外社区的建立也是对开源精神的一种致敬。开源精神强调的是开放、协作和共享，而这些价值观在全球范围内都是通用的。当我们向海外扩展时，我们不仅在分享代码，更在传播这种包容和合作的精神。 此外，对于开源项目而言，海外社区的建立还意味着更广阔的市场和使用场景。不同的地区和文化背景下，用户对技术的需求和应用方式可能截然不同。这些多样性的输入是项目发展不可或缺的，它们有助于项目更全面地成长，更好地服务于全球用户。 我从大一开始接触 Github ，这个成功打开我通往未来的钥匙。 从2020年左右我开始接触开源，觉得开源比业务代码更有意义。因为开源不仅有技术积累，而且能把你学到的东西分享给其他人，一起成长，所以开源对程序员来说是一个双赢的事。 最开始的时候，我通过学习做笔记，分享笔记到 GitHub ，到后面做项目，参与到一些顶级的开源项目中来，然后慢慢的追求精益。整个过程，我很清晰的看到自己的成长。 甚至我的代码，就像 Git 或者 区块链的默克尔树结构，一步步的串起来记录，每当一个时间段，看到以前的 PR ，满满的都是回忆和尴尬 … 同样，我也是一个云原生的爱好者。 在如今这个时代，开源已经成为了一个不可逆的潮流，尤其是在云原生的领域。以微软为例，他们在 Github 上的开源项目贡献位居全球前列，这充分体现了他们对开源的全面拥抱。在云原生时代，如果你不拥抱开源，不利用开源组件去构建和优化你的核心系统，很可能会在激烈的市场竞争中落后。云原生技术的迅猛发展要求企业和开发者必须快速适应新技术和方法论，而开源社区正是这种创新和合作的孵化器。在这个时代，开源不仅仅是技术选择，更是一种必要的战略思维。 开源社区国际化选择：第一站，启航 美国：开源发展的领头羊 美国仍然是全球最大的开发者社区，拥有超过2000万的开发者，过去一年增长了21%。美国的开源社区历史悠久且成熟，是全球开源活动的重要推动者。 亚太地区：快速增长的新星 亚太地区，尤其是印度、日本和新加坡，正经历着显著的开源社区增长。印度的开发者社区增长尤为显著，预计到2027年将超过美国，成为全球最大的开源社区。 非洲：充满潜力的新兴市场 非洲各地区，尤其是尼日利亚、加纳和肯尼亚，也在迅速发展成为技术公司的新兴枢纽。这些地区的开发者数量每年都在显著增长。 南美洲：稳健增长的活跃区域 南美洲的开发者社区，特别是在阿根廷和巴西，也在持续增长，与亚太和非洲的增长速度相仿。 欧洲：稳定增长的成熟市场 欧洲的开源社区虽然增长速度较美国慢，但在西班牙、德国和英国等国家仍保持稳定增长。 Github 年度总结分析 2023 年 Github 年度报告精华： 生成式 AI 项目和个人贡献者数量的显著增长 ...

介绍 关于 kustomize github 地址 Get Started Kustomize 是一个专为 Kubernetes 设计的开源配置管理工具，它能帮助用户定制 Kubernetes 对象，并以声明式的方式管理这些对象，而无需修改原始的 YAML 文件1 。这意味着你可以保留应用和组件的基本设置，同时通过应用名为“补丁”的声明式 YAML 文档来覆盖默认设置，而不会更改原始文件 。Kustomize 提供了一种声明式的方法，符合 Kubernetes 的哲学，并且能够以一种可重用、快速生成、易于调试和可伸缩的方式定制 Kubernetes 配置。 Kustomize 的主要功能包括: 声明式配置: 允许你以声明式的方式定义和管理 Kubernetes 对象，例如部署、Daemonsets、服务、ConfigMaps 等，为多个环境提供支持，而无需修改原始的 YAML 文件 配置层叠: 通过利用层叠来保留应用和组件的基本设置，并通过覆盖声明式的 YAML 文档（称为补丁）来选择性地覆盖默认设置 集成与独立使用: Kustomize 可以作为一个独立的工具使用，或者与 kubectl 结合使用。从 Kubernetes 1.14 版本开始，kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象 Kustomize 提供了一种自定义 Kubernetes 资源配置的解决方案，该方案摆脱了模板和 DSL。 版本关系 & kubectl 集成 要查找kubectl最新版本中嵌入的kustomize版本，请运行 kubectl version ： $ kubectl version --short --client Client Version: v1.26.0 Kustomize Version: v4.5.7 kubectl v1.14中添加了v2.0.3的kustomize构建流。kubectl中的kustomize流在kubectl v1.21更新到v4.0.5之前一直冻结在v2.0.3。它将定期更新，这些更新将反映在Kubernetes发布说明中。 ...

需求 OpenIM 提供了多种公共的镜像注册地址，比如说 aliyun， github， Docker hub ~ 阅读 https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/images.md 获取更多的镜像构建指南。 大部分企业都会选择自己做镜像仓库，使用 Harbor 来搭建企业级的镜像仓库，将它集成 CICD Pipeline 流程中，最终替换 Docker Hub，进一步降低镜像存储的成本。 此外，在生产环境下，Harbor 一般都会开启 TLS，所以你还需要准备一个可用的域名。 中国的服务器使用域名，需要对域名进行备案 安装 Helm Helm，以及 集群的部署参考 https://github.com/openimsdk/open-im-server/tree/main/deployments 安装 Cert-manager 接下来我们安装 Cert-manager，它会为我们自动签发免费的 Let’s Encrypt HTTPS 证书，并在过期前自动续期。 首先，运行 helm repo add 命令添加官方 Helm 仓库。 $ helm repo add jetstack https://charts.jetstack.io 然后，运行 helm repo update 更新本地缓存。 $ helm repo update 接下来，运行 helm install 来安装 Cert-manager。 $ helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1.10.0 \ --set ingressShim.defaultIssuerName=letsencrypt-prod \ --set ingressShim.defaultIssuerKind=ClusterIssuer \ --set ingressShim.defaultIssuerGroup=cert-manager.io \ --set installCRDs=true 此外，还需要为 Cert-manager 创建 ClusterIssuer，用来提供签发机构。将下面的内容保存为 cluster-issuer.yaml。 ...

云原生领域中GitHub开源Go项目的自动化测试实践与策略 介绍 作为 Github 上的 热门项目 OpenIM，如何在云原生时代中创造出价值，这是非常重要的，OpenIM 是一个优质的小团队，我们在自动化中并没有特别深入的见解。 使用 GitHub Actions 进行持续集成和持续交付 (CI/CD): GitHub Actions 提供了一个平台，可以自动构建和测试 Go 语言项目。通过配置 GitHub Actions 工作流，你可以在代码更改时自动运行测试，确保代码的质量和功能 。 KubeVela 项目实践: KubeVela 是一个 Go 语言的云原生和开源项目，它展示了如何在云原生环境中组织 CI/CD 过程，包括自动化测试。KubeVela 使用声明性工作流来协调 CI/CD 过程，你可以参考 KubeVela 的 GitHub 仓库来理解和应用这些实践3 4 [5](https://github.com/kubevela/workflow#:~:text=KubeVela Workflow is an open,engine in your own repository)。 云原生测试框架与工具: 在云原生开发中，合约测试（Contract Testing）是一种常见的测试实践，它确保服务间的通信符合预定义的 API 协议。例如，Cloud-Native Toolkit 中使用 Pact 进行合约测试。通过编写和集成测试，你可以验证服务间的通信是否符合预期6 。 代码覆盖率检查: 在进行自动化测试时，检查代码覆盖率是一个好的实践。许多测试框架内置了代码覆盖率检查功能，可以配置它们来报告测试的代码覆盖率。例如，使用 SonarQube 工具来读取和报告代码覆盖率信息6 。 利用开源工具和框架: 你可以利用开源工具和框架来进行测试，例如使用 Cypress 进行云原生应用的测试[7](https://dev.to/litmus-chaos/cloud-native-application-testing-automation-2bh5#:~:text=Cloud Native Application %26 Testing,Testing Using Cypress for)。还有其他的项目和资源，例如在 GitHub 上的 learning-cloud-native-go/myapp 仓库，提供了云原生 Go 项目的完成示例，你可以参考这些示例来理解和应用云原生测试实践[8](https://medium.com/learning-cloud-native-go/lets-get-it-started-dc4634ef03b#:~:text=The completed project can be,The completed API)。 自定义自动化测试流程: 通过结合 GitHub Actions 和开源工具，你可以定制项目的 CI/CD 流程，包括自动化测试和验证步骤9 。 自动化测试的价值量化 自动化很明显，是后期的手动成本很低，也就是说，随着时间的推移，自动化运行的次数增多，自动化的价值 ROI 变高 ...

调度器 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.kubernetes.io/preferAvoidPods字段判断，权重为10000，避免其他优先级策略的影响 NodeAffinityPriority：优先调度到匹配NodeAffinity的节点上。 TaintTolerationPriority：优先调度到匹配TaintToleration的节点上。 ServiceSpreadingPriority：尽量将同一个service的Pod分布到不同节点上，已经被SelectorSpreadPriority替代( 默认未使用)。 EqualPriority：将所有节点的优先级设置为1 (默认未使用) ImageLocalityPriority：尽量将使用大镜像的容器调度到已经下拉了该镜像的节点上(默认未使用) MostRequestedPriority：尽量调度到已经使用过的Node.上，特别适用于cluster-autoscaler (默认未使用) 资源需求 CPU ...

深入理解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附加到上下文中。 **WithMaxInFlightLimit()：**在maxinflight.go中定义，对当前的请求数量进行限制。 **WithTimeoutForNonLongRunningRequests()：**在timeout.go中定义，超时暂停非长时间运行请求（如大多数GET，PUT，POST，DELETE请求），这种请求与长时间运行请求（如watch和proxy请求）正好相反。 **WithPanicRecovery()：**在wrap.go中定义，包装一个http Handler来恢复和记录报错。 **WithCORS()：**在cors.go中定义，提供了一个CORS实现；CORS代表跨原始资源共享（Cross-Origin Resource Sharing），是一种允许嵌入在HTML页面中的JavaScript生成XMLHttpRequests请求到一个域（domain）的机制，这个域不同于JavaScript的初始起源。 **WithAuthentication()：**在authentication.go中定义，尝试以用户身份对给定的请求进行验证，并将用户信息存储在提供的上下文中。成功后，授权HTTP header将从请求中删除。 ...