云原生 on 小盒子的技术分享

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

Wed, 04 Mar 2026 08:41:32 +0000

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

如果你要招募一位主刀医生，你会让他当场默写《人体解剖学》的第一章吗？如果你要找一位米其林大厨，你会蒙住他的眼睛，让他比赛在一分钟内切出多少根标准厚度的土豆丝吗？

显然不会。但在如今的软件工程招聘中，我们却在做着同样荒谬的事情：让那些在复杂的业务泥潭中摸爬滚打、主导过千万级并发系统、熟练操纵复杂云原生架构的资深工程师，站在白板前，徒手写出一个“翻转二叉树”或者“接雨水”的最佳时间复杂度解法。

不知从何时起，“刷 LeetCode”已经从一种思维训练，演变成了一场病态的军备竞赛。是时候戳破这个泡沫了：LeetCode 根本选拔不出优秀的软件工程师，它正在毁掉我们的行业生态。

一、真实的工程世界，从来不是一道“闭卷考试”

让我们先来看看，一个现代软件工程师的真实一天是怎样度过的。

你可能会花一整个上午，在一堆没有注释的“屎山”代码中追踪一个诡异的内存泄漏问题；你可能会在下午和产品经理反复拉扯，确定一个新功能在微服务架构下的 API 边界；你可能会在排查为什么 Kubernetes 集群里的 HPA（水平Pod自动扩缩容）没有按预期触发，或者研究 Istio 网关的流量路由策略。

如果你身处最前沿的 AI 领域，你可能正在评估是用 LangGraph 还是 AutoGen 来构建多 Agent 协同流，或者在调试大模型 API 的 Top-p 采样参数，试图让生成的回答既准确又具有随机性。甚至，在业余时间，你可能在设计一款解决自己痛点的小工具——比如一个用来清理、分类和管理繁杂书签的浏览器插件。

这些工作有一个共同点：它们都是极其复杂的、高度依赖上下文的、开放性的问题。

而在真实的工作环境中，我们解决这些问题依靠的是什么？

1.查阅文档与搜索能力：我们有 Google、有官方文档、有开源社区，甚至现在还有 AI 助手。

2.调试与试错能力：我们通过打日志、单步调试、看监控指标来定位问题。

3.架构视野与经验直觉：我们知道什么时候该用单例模式，什么时候该用工厂方法；我们知道在高并发下如何设计缓存策略，如何保证数据一致性。

4.沟通与协作：我们需要阅读别人的代码，也需要让别人看懂我们的设计。

反观 LeetCode 面试，它创造了一个极其不真实的无菌实验室环境：

●题目边界清晰，输入输出明确。

●只有单一的“最优解”（通常是时间复杂度和空间复杂度的极限）。

●不允许查阅文档，甚至不允许使用趁手的 IDE（有时只能在网页的纯文本框里写代码）。

●偏离日常使用的技术栈（你可能用 Python 写了十几年业务，却要用 C++ 的思维去考虑指针和内存管理）。

这就像是要求一个现代战争中的王牌飞行员，在面试时去比拼谁的射箭准头更好。它考察的不是“解决问题的能力”，而是“在极其受限条件下的默写能力”。

二、刷题面试，正在惩罚真正有经验的“老兵”

在软件开发领域，经验是一笔巨大的财富。一个拥有 10 年、15 年工作经验的研发架构师，他最大的价值并不在于写代码的速度有多快，而在于他踩过足够多的坑。

资深工程师知道，一个系统最大的危机往往不是算法复杂度从变成了（很多时候硬件资源和缓存机制完全能弥补），而是：

●数据库连接池配置不当导致的雪崩。

●缺乏熔断降级机制导致的服务级联故障。

●领域模型设计错误导致的后续需求无法扩展。

●业务逻辑耦合过深导致的测试困难。

然而，当这位资深架构师带着一身的实战本领走进面试房间时，等待他的却是一道“动态规划（DP）”的 Hard 题。

这是一种极大的资源浪费。一个能在生产环境中稳稳掌控全局、能设计出高可用 AI 基础设施、能带领团队攻坚克难的资深人才，仅仅因为最近几个月忙于项目交付、或者忙于应对生活中的变故（比如寻找新机会、照顾家庭），没有抽出几百个小时去死记硬背算法题库，就被无情地贴上“技术不过关”的标签淘汰出局。

这种现象导致了一个极其荒谬的倒挂：

那些刚刚毕业、没有写过一行生产环境代码、不懂得什么是持续集成、不知道如何进行线上排障的学生，只要花三个月把 LeetCode 刷个滚瓜烂熟，就能在面试中大杀四方；而那些真正在一线扛过枪、打过仗，能够解决复杂工程灾难的老兵，却在白板前因为忘记了一个状态转移方程而涨红了脸。

企业以为自己招到了“绝顶聪明”的天才，结果新人一入职，面对极其复杂的微服务依赖和一团乱麻的业务逻辑，立刻束手无策。因为真实的业务系统里，没有人会为你准备好整洁的 ListNode 或者 TreeNode。

三、算法题面试的本质：一场低效的“智商服从性测试”

为什么即便怨声载道，这么多公司依然痴迷于 LeetCode 面试？很多面试官会辩解说：“算法题能考察候选人的聪明程度和逻辑思维。”

这其实是一个伪命题。

1. 算法题早就不测智商了，它只测“准备度”。

在互联网早期，用算法题面试确实能筛选出一些思维敏捷的人，因为那时没有题库。但现在，LeetCode 已经有上千道题，“面经”满天飞。面试不仅变成了开卷考试的闭卷化，更变成了一门应试产业。能解出 Hard 题，往往不意味着你绝顶聪明，只意味着你刷到过原题，或者你花了大把时间去背诵套路。这充其量是一场“服从性测试”——看候选人愿不愿意为了这份工作去吃毫无意义的苦。

2. 忽视了工程中最关键的“可维护性”。

在 LeetCode 的评价体系里，“代码跑得快”是唯一的真理。哪怕你的代码里全是 i, j, k, dp, res 这种毫无语义的变量名，哪怕你的逻辑晦涩难懂如天书，只要能 AC（Accepted），你就是赢家。

但在实际工程中，这种代码是灾难。好的工程师写出的代码是给人看的，其次才是给机器执行的。如果你的代码在生产环境中出了 Bug，同事半夜被叫醒排查，看到满屏追求极致技巧却毫无注释的“炫技代码”，他大概率会在心里把你骂上一万遍。LeetCode 培养出的“做题家”思维，与团队协作所需的工程素养往往是背道而驰的。

3. 面试官的“安全牌”与偷懒。

其实，很多面试官也根本不知道该怎么面试。对他们来说，从题库里随机抽一道题扔给候选人，是最省事、最没有风险的做法。如果你没写出来，那是你不行，面试官不需要承担招错人的责任。这种做法掩盖了面试官自身架构视野和识人能力的匮乏。要深入了解一个人的项目经验、技术深度和系统设计能力，需要面试官投入极大的精力和极高的技术水平去进行深度的技术探讨，而“考一道题”则轻易地把压力全抛给了候选人。

四、如何打破僵局：回归工程本质的面试方法

批判之后，我们需要建设。如果不考 LeetCode，我们该怎么筛选优秀的软件工程师？真正的面试，应该是一场对日常工作的高度模拟。

1. 结对编程 (Pair Programming)

不要让候选人在白板上写代码，给他一台配置好 IDE 的电脑。面试官准备一个真实但简化过的业务小项目，或者直接在公司的一个开源代码分支上，两人结对协作。

●“我们现在有一个 Python 的服务端，用 FastAPI 写的，现在需要增加一个中间件来做简单的限流，你打算怎么做？”

●允许候选人查阅文档，允许使用 Google。

●观察他的编码习惯、他对框架的熟悉程度、他如何拆解问题，以及更重要的——他如何与你沟通和协作。

2. 代码审查 (Code Review)

给候选人一段存在各种“坑”的代码（可以是以前团队写出的真实烂代码，隐去敏感信息）。这段代码可能存在并发竞争、内存泄漏、或者设计模式的滥用。

让候选人进行 Code Review。优秀的工程师能立刻嗅出代码中的“坏味道”，并提出合理的重构建议。这比让他默写快速排序要有效得多。

3. 深度系统设计与项目复盘

抛弃那些假大空的“如何设计一个推特”的八股文。让候选人深度讲解他简历中最自豪的一个项目。

●“你在简历中提到主导了容器化改造，能画一下当时的 Kubernetes 架构图吗？”

●“在使用 Ingress 和服务网格（比如 APISIX 或 Istio）时，你们遇到了什么性能瓶颈？是如何排查的？”

●“你提到在做 AI 相关的研发，在整合底层大模型接口时，你们是如何处理长上下文带来的延迟问题和 token 消耗的？”

通过深度的追问，直到触及他的知识边界。真正的行家，在谈论自己亲手一砖一瓦建起来的系统时，眼里是有光的，细节是经得起推敲的。

4. 聊聊他创造的“小玩意儿”

一个真正的工程师，往往是对技术充满热情的创造者。与其问算法，不如问问他平时都在折腾什么。如果他告诉你，他因为受不了浏览器书签太乱，正在自己设计开发一个管理书签的插件；或者他为了解某种新技术栈，自己搭了一个爬虫和数据展示网站。请让他展示一下！这种对痛点的敏锐察觉和动手解决问题的能力，是任何算法题都无法衡量出的核心特质。

五、结语：放过工程师，也放过企业自己

技术招聘走到今天“无算法不面试”的地步，是整个行业的悲哀。它消耗了工程师们原本可以用来学习新框架、钻研底层原理、甚至陪伴家人的宝贵精力；它也让企业错失了大量踏实肯干、经验丰富的实战派人才。

编程，是一门结合了逻辑、工程、设计甚至艺术的创造性活动。它不该被简化为一场机械的背诵比赛。

作为面试官，下次当你准备掏出一道 LeetCode Hard 题时，不妨停下来问问自己：“这道题，真的能帮我找到那个能和我并肩作战、一起扛住双十一流量洪峰、一起在深夜排查诡异 Bug 的可靠队友吗？”

如果不能，请放下那道该死的算法题，和候选人像真正的工程师一样，聊聊真实的架构，看看真实的代码。

把时间还给工程，把尊严还给工程师。

云原生，你真的懂了吗？

Sat, 22 Feb 2025 04:00:00 +0000

啥是云？

说起云原生（cloud native），就不得不说明一下 “云” 是啥。

简单理解，云就是 “云计算”，如果给它下个定义的话是这样的：

云" 特指以云计算模型构建的现代化动态环境

为什么叫云呢？它怎么不叫其他的什么呢？

这个吧，就像你问马云为什么叫马云一样，那是因为给他起名的家长就是这么定的。对，云计算也是如此，计算机领域的专家就是这么定的。后来成了专业术语，大家都这么说。那你说叫 “云” 有没有道理呢？有道理。

我们类比地看，如果你将 “资源” 看成水的话，那么在天空上自由自在、飘来飘去的云就是资源的载体，在你有需要的时候，“呼风唤雨🌧️” ，一朵带着雨水（资源）的积雨云就能为你带来一场甘霖（你需要的资源）。

云在天上，不在地下，不像以前（过去的架构），你想吃水了得自己挖井，现在你可以 “呼风唤雨” 叫云给你水。而且很好管理和维护。所以你看，用 “云” 这个字还是有道理的。

“云” 可以有多种形态

云还有多种形态，一般来说有以下三种：

公有云（Public Cloud）：由第三方云计算提供商（如 AWS、Azure、Google Cloud、阿里云、腾讯云等）拥有和运营，面向公众提供服务。
私有云（Private Cloud）：由企业或组织自己拥有和运营，仅供内部使用。私有云可以部署在企业自己的数据中心，也可以托管给第三方提供商。
混合云（Hybrid Cloud）：结合了公有云和私有云的优势，允许应用程序和数据在两者之间迁移和共享。

还是用吃水比喻，公有云就像 “自来水”，打开水管就能喝。私有云就像自己找水源，自己挖井，自己舀水喝。混合云自然就是这两种的混合。

资源有啥？

说完了云，我们该说水了，云是提供资源的，那么具体有哪些资源呢？什么东西是云可以提供给我们的呢？你可能想到了：“嗨，不就是服务器嘛”。

其实 “资源” 是一个多维度的概念，远不止硬件设备。我们展开说说。

首先是：基础资源，它包括：

计算资源（CPU/GPU/FPGA）
存储资源（磁盘 / SSD / 对象存储）
网络资源（带宽 / IP / 负载均衡）
内存资源（RAM）

然后是抽象服务，比如：

容器编排（Kubernetes（EKS/GKE/ACK）、Nomad）
数据库服务（AWS RDS、阿里云 RDS）
消息队列（Kafka 云托管、AWS SQS、RabbitMQ）

接着是管理与安全，比如：

身份权限（AWS IAM、阿里云 RAM、Azure AD）
监控告警（Prometheus 云托管、Datadog、阿里云 ARMS）
日志分析（ELK Stack 云服务、Splunk）
安全防御（阿里云 WAF）

最后是高阶能力，比如：

Serverless（AWS Lambda、阿里云 FC）
服务网格（Istio、Linkerd）
边缘计算（AWS Wavelength、阿里云 ENS）
量子计算（AWS Braket、Azure Quantum）

我上面举的只是一些常见的例子，其实每一个分类下的资源条目是非常多的。所以你看，“资源” 可不止服务器那么简单，它是多维度的。现在几乎你能用的到的东西都上云了，都是资源。就算没有，经不住人家云厂商包装啊，只要你有需求，人家就有产品卖你，哈哈。

云原生

云其实还是比较好理解的，但是云原生（cloud native）就比较抽象了，在我刚接触这个概念的时候是一头雾水，无论别人给我讲，还是我给别人讲总是说不清楚，或者人家听不懂。

我们还是先来说说定义吧，我找到 CNCF （https://github.com/cncf/toc/blob/main/DEFINITION.md）的一个定义，算比较权威了。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

说实话，如果你没有在这个领域干过，光看定义是不容易理解的。甚至就算在云原生环境下从事开发的工程师，如果不认真思考、理解，也不能把什么是“云原生” 讲的很明白。

原因是这个概念本来就比较抽象。所以我不用 CNCF 的定义，换一种说法来描述一下什么是 “云原生”

云原生是一种以云计算基础设施为基石，通过容器化封装、微服务拆分、声明式 API 和自动化运维，将应用的非功能需求（如弹性扩缩、故障自愈、安全策略）交由云平台管理的架构范式。其本质是通过技术手段让业务代码与底层资源解耦，使开发者只需关注业务逻辑，而由云平台自动处理部署、监控、容灾等复杂性。

你看，我这样说是不是清晰一些了？更好理解一些了？还没有？接着往下看。

本质

透过现象看本质，概念怎么说都行，重要的是要理解这个东西的本质。

那我们就来看一看 “云原生” 的本质：

云原生并非单纯的技术集合，而是一种 “以应用为中心” 的思维模式。它通过标准化技术栈（容器 / K8s / 微服务），将云计算从 “资源层” 提升到 “应用层”，让企业能像使用水电一样按需使用计算能力。它的目标是让技术复杂性对业务透明化。

说到这里，我们就不得不说一下为什么要使用或推崇“云原生”了。

云原生的出现源于传统应用架构在云计算时代的局限性。

传统架构有许多痛点，做的传统开发的同学一定都知道，比如：

部署效率低：传统应用依赖物理服务器或虚拟机，部署流程复杂（如手动配置环境、依赖冲突）。
扩展性差：单体架构难以应对流量突增，扩容需要数小时甚至数天。
运维成本高：故障恢复、监控、日志收集等运维工作需人工干预。
环境不一致：开发、测试、生产环境差异导致 “在我机器上能跑” 的问题。

采用 “云原生” 技术栈及应用架构可以有效的解决上面的所有问题。

什么是不可替代的？

不得不说，Docker 和 Kubernetes 技术的出现给了 “云原生” 极大的助力。那如果没有 Docker 和 Kubernetes 呢？云原生这个概念还立得住吗？

其实，云原生概念的出现（2010 年 Netflix 提出）比 Docker（2013）和 Kubernetes（2014）更早。核心思想在容器技术普及前就已萌芽。所以：云原生本质是一种架构哲学，而非特定技术捆绑

那么我们紧接着下一个问题就是：什么是云原生的核心内容，有什么是缺一不可的呢？或者说缺了什么就不能算是云原生了呢？

总结来说，有四大支柱：

弹性伸缩（Elasticity）

必须能力：根据负载自动扩缩资源
替代方案：AWS Lambda（Serverless）、Nomad（非 K8s 编排器）

故障自愈（Resilience）

必须能力：服务熔断、重试、健康检查
替代方案：Hystrix（微服务容错库）+ Consul（服务发现）

声明式管理（Declarative）

必须能力：通过 YAML/JSON 描述目标状态，而非手动操作
替代方案：Terraform（基础设施即代码）+ Ansible（配置管理）

自动化交付（Automation）

必须能力：CI/CD 流水线、蓝绿部署
替代方案：GitLab CI + Spinnaker（持续交付平台）

云原生的 “复杂性悖论”

云原生看起来真好呀，但事实是这样吗？对于软件开发，我们都知道一句著名的话：“没有银弹”，是的。云原生也不是哪儿哪儿都好，它也有它的问题。

云原生存在一个看似矛盾的现象：它承诺降低业务复杂性，却引入了新的技术复杂性。

这种矛盾的核心在于技术栈的 “分层复杂性转移”：

传统架构的复杂性集中在应用层（如单体重构困难、环境配置混乱）
云原生的复杂性下沉到基础设施层（如 K8s 集群运维、Istio 配置）

对企业而言，这相当于用 “可控的工程复杂度” 替代 “不可控的业务阻塞风险”。但关键在于，这种转移是否真正带来净收益。

说白了，你要会“算账”，在成本一定的情况下，要有所取舍，到底要不要上“云原生”，不是技术本身决定的。

云原生有它的显性与隐性成本：

技术债务：K8s 版本升级兼容性问题、Helm Chart 维护
人力成本：需要 DevOps 工程师（平均薪资比开发高 30%+）
认知负担：团队需掌握容器、服务网格、声明式 API 等新范式
工具链成本：监控（Prometheus+AlertManager）、日志（EFK）、追踪（Jaeger）的集成和维护

有成本当然也有收益：

部署效率：从手动部署 1 小时 → 全自动 CI/CD 5 分钟（效率提升 12 倍）
资源利用率：虚拟机静态分配 → 容器动态调度（CPU 利用率从 15% 提升至 60%+）
故障恢复速度：人工排查 1 小时 → 自动熔断 + 滚动更新（MTTR 从 60 分钟降至 5 分钟）
业务敏捷性：新功能上线周期从 1 个月 → 1 周（迭代速度提升 4 倍）

所以，关键是要根据你的实际情况 “算账”，一般来说，当企业规模超过临界点（通常≥50 个微服务 / 日部署次数≥10 次），云原生的收益将显著超越成本。

结论

所以说了半天云原生到底是什么？我不知道你明白了没有，我们上面林林总总写了那么多技术点，如果初次接触确实很头大。但这不重要。

因为：云原生不是工具集，而是「工业化软件生产」的方法论升级

用制造业的思维来理解：

传统软件交付 ≈ 手工作坊（每个陶器需手工塑形、烧制）
云原生交付 ≈ 汽车生产线（标准化零件 + 自动化流水线 + 质量检测体系）

如果你面试的时候，面试官让你谈谈对云原生的理解，我希望你能够把这篇文章的精华吸收了，从一个比较高的层次来谈，我不希望给你一个中规中矩的回答模板，虽然它是正确的，比如以下这样：

“云原生是云计算时代的一种架构范式，旨在通过标准化技术栈（如容器、K8s）和自动化运维体系，将非业务功能（如弹性扩缩、故障自愈）从应用代码中剥离，由云平台接管。其核心驱动力是解决传统单体应用部署慢、环境不一致、扩展难的问题。

从技术分层看，云原生包含：

基础设施层：Docker 实现环境一致性，K8s 完成资源调度，比如我们通过 Deployment 的滚动更新实现零停机发布；

应用架构层：微服务拆分业务能力，Istio 服务网格处理服务间通信的熔断、监控，例如在订单服务中配置超时自动重试；

交付运维层：GitOps 工具链（如 Argo CD）确保声明式配置的版本可控，配合 Prometheus+Grafana 实现实时监控。

关键设计原则包括不可变基础设施（容器镜像一次构建多次运行）、声明式 API（通过 YAML 描述目标状态而非手动操作）。但引入云原生也带来挑战，比如团队需要掌握复杂的 K8s 生态，我们通过建设内部开发者平台（IDP）封装底层细节，让开发者只需关注业务代码。”

云原生应用

什么样的应用是云原生的？

一个应用是否云原生，而要看是否具备以下特征：

容器化部署：

应用打包为 Docker 镜像，在 Kubernetes 集群中运行。
示例：电商大促时，通过 HPA（水平扩缩）自动增加订单处理服务的 Pod 数量。

微服务架构：

业务拆分为独立服务（如用户服务、支付服务），通过 API 通信。
示例：视频网站将视频转码服务独立部署，利用 GPU 节点加速，不影响主站稳定性。

DevOps 流水线：

代码提交后自动触发 CI/CD，完成测试、镜像构建、灰度发布。
示例：金融 App 通过蓝绿部署实现零停机更新，降低发布风险。

依赖云原生中间件：

使用云托管的数据库（如 AWS RDS）、消息队列（如 Kafka on K8s）、缓存（如 Redis Cluster）。
示例：社交平台用云原生数据库 TiDB 处理海量关系数据，自动分片扩容。

跨云与混合云兼容：

应用设计不绑定特定云厂商，可在 AWS、Azure、私有云间迁移。
示例：跨国企业采用 Anthos 实现跨公有云和本地数据中心的统一管理。

最后

云原生不是终点，而是通往智能软件时代的必由之路。当我们将视角从工具本身移开，看到的是一场关于效率、可靠性与创新速度的认知革命。正如 Linux 之父 Linus Torvalds 所说：“技术终将老去，但优秀的架构思想永存。” 在这场变革中，比掌握某个工具更重要的，是建立持续进化的云原生思维体系。

容器编排工具的演进：从 Docker 到 Kubernetes

Sat, 10 Aug 2024 05:18:45 +0000

在现代应用部署中，Docker 和其他容器引擎为服务器端应用程序的部署提供了极大的便利。然而，随着应用和服务数量的增加，管理这些容器变得越来越困难。这催生了一类被称为容器编排器的工具，其中最为知名的莫过于 Kubernetes。容器编排的历史可以分为 Kubernetes 出现之前和之后两个阶段。

容器的便利与妥协

容器的使用虽然便利，但也带来了一些妥协。严格遵循 Docker 的理念，每个服务都应有其独立的容器，这将导致运行大量的容器。即使是一个简单的数据库网页界面，也可能需要分别运行数据库服务器、应用程序，以及可能包括用于处理静态文件的 Web 服务器、用于终止 SSL/TLS 连接的代理服务器、用作缓存的键值存储，甚至用于处理后台作业和计划任务的第二个应用程序容器。

负责多个此类应用程序的管理员很快就会意识到，需要一个工具来简化管理任务，这时容器编排工具应运而生。容器编排器可以将多个容器作为一个单元来管理，并将多个服务器结合成一个集群，自动分配容器工作负载到集群节点中。

Docker Compose 与 Swarm

Docker Compose 虽然不完全是一个编排器，但它是 Docker 首次尝试创建的工具，用于更轻松地管理由多个容器组成的应用程序。它使用 YAML 格式的文件，通常命名为docker-compose.yml。Compose 读取该文件，并使用 Docker API 创建所需的资源，同时为所有资源添加标签，以便在创建后作为一组进行管理。

Compose 文件中可以定义三种资源：

服务（services）： 包含要启动的容器声明。每个条目相当于一个docker run命令。
网络（networks）： 声明可以附加到容器的网络。每个条目相当于一个docker network create命令。
卷（volumes）： 定义可以附加到容器的命名卷。每个条目相当于一个docker volume create命令。

Compose 提供了一种更方便的方式来管理由多个容器组成的应用程序，但在其最初版本中，它仅支持单个主机；所有创建的容器都在同一台机器上运行。为了扩展到多个主机，Docker 在 2016 年引入了 Swarm 模式。这是 Docker 的第二个名为“Swarm”的产品，前一个产品于 2014 年推出，采用了完全不同的方法在多个主机上运行容器，但现在已不再维护。

Swarm 模式包含在 Docker 中，无需额外的软件即可使用。创建集群只需在初始节点上运行docker swarm init，然后在每个其他节点上运行docker swarm join。Swarm 集群包含两种类型的节点：管理节点和工作节点。管理节点提供 API 以在集群上启动容器，并使用基于 Raft 一致性算法的协议进行通信，以在所有管理节点之间同步集群状态。工作节点则负责运行容器。

通过 Compose 文件在 Swarm 上部署服务。Swarm 通过为每个服务添加一个deploy键扩展了 Compose 格式，该键指定服务应该运行的实例数量及其运行的节点。然而，这导致 Compose 和 Swarm 之间出现了一些分歧，某些选项如 CPU 和内存配额需要根据使用的工具以不同的方式指定。在此分歧期间，为 Swarm 准备的文件被称为“堆栈文件”而非 Compose 文件，幸好这些差异在当前版本的 Swarm 和 Compose 中已被平滑处理，Compose 格式现在有一个开放规范及其 GitHub 组织提供的参考实现。

关于 Swarm 的未来存在一些不确定性。它曾经是名为 Docker Cloud 的服务的骨干，但该服务在 2018 年突然关闭。它还被宣传为 Docker 企业版的关键特性，但该产品已售予另一家公司，现以 Mirantis Kubernetes Engine 的名义进行市场推广。同时，最新版本的 Compose 已经获得了将容器部署到 Amazon 和 Microsoft 托管服务的能力。虽然没有宣布弃用，但最近也没有任何其他类型的公告；在 Docker 网站上搜索“Swarm”一词，仅能找到一些提及。

Kubernetes

Kubernetes（有时称为 k8s）是受 Google 内部工具 Borg 启发的项目。Kubernetes 管理资源并协调在多达数千个节点的集群上运行工作负载；它在容器编排领域的统治地位如同 Google 在搜索领域的统治地位。Google 曾在 2014 年希望与 Docker 在 Kubernetes 开发上合作，但 Docker 决定走自己的路，发展 Swarm。相反，Kubernetes 在云原生计算基金会（CNCF）的支持下成长。到 2017 年，Kubernetes 的流行度已高到 Docker 宣布将其集成到 Docker 产品中。

Kubernetes 以其复杂性而闻名。手动设置一个新集群是一项繁杂的任务，除了 Kubernetes 本身外，管理员还需选择和配置若干第三方组件。就像 Linux 内核需要结合其他软件以构成完整的操作系统一样，Kubernetes 仅是一个编排器，需结合其他软件以构成完整的集群。它需要容器引擎来运行其容器，还需要网络和持久化卷的插件。

Kubernetes 发行版存在以填补这一空白。像 Linux 发行版一样，Kubernetes 发行版将 Kubernetes 与安装程序和精选的第三方组件捆绑在一起。不同的发行版存在以满足不同的需求；几乎每家规模一定的科技公司都有其自己的发行版和/或托管产品，以迎合企业需求。minikube 项目为开发者提供了一个更简便的本地实验环境。

Kubernetes 的组成结构

一个 Kubernetes 集群包含多个软件组件。集群中的每个节点都会运行一个称为 kubelet 的代理，以保持集群成员资格并接受来自集群的工作，容器引擎，以及用于启用与其他节点上运行的容器进行网络通信的 kube-proxy。

保持集群状态并对资源分配做出决策的组件被统称为控制平面，这包括一个分布式键值存储（etcd），一个将工作分配给集群节点的调度器，以及一个或多个控制器进程，这些进程对集群状态的变化做出反应，并触发任何必要的操作以使实际状态与所需状态相匹配。用户和集群节点通过 Kubernetes API 服务器与控制平面进行交互。为了实现变更，用户通过 API 服务器设置集群的期望状态，而 kubelet 将每个集群节点的实际状态报告给控制器进程。

Kubernetes 在一个称为 Pod 的抽象中运行容器，Pod 可以包含一个或多个容器，尽管不建议在一个 Pod 中运行多个服务的容器。相反，通常一个 Pod 会有一个提供服务的主容器，可能还有一个或多个“sidecar”容器，用于从主容器中运行的服务收集指标或日志。Pod 中的所有容器都会一起调度在同一台机器上，并共享一个网络命名空间——在同一个 Pod 中运行的容器可以通过回环接口互相通信。每个 Pod 在集群内都会收到一个唯一的 IP 地址。在不同 Pod 中运行的容器可以使用它们的集群 IP 地址相互通信。

一个 Pod 指定了一组要运行的容器，但 Pod 的定义并没有说明要在哪些地方运行这些容器，或运行多久——在没有这些信息的情况下，Kubernetes 会在集群中某处启动容器，但不会在它们退出时重新启动它们，并可能在控制平面决定其他工作负载需要它们使用的资源时突然终止它们。因此，Pod 很少单独使用；相反，Pod 的定义通常被封装在一个 Deployment 对象中，用于定义一个持久化服务。像 Compose 和 Swarm 一样，Kubernetes 管理的对象是在 YAML 中声明的；对于 Kubernetes，这些 YAML 声明通过 kubectl 工具提交到集群。

除了 Pod 和 Deployment，Kubernetes 还可以管理许多其他类型的对象，例如负载均衡器和授权策略。支持的 API 列表在不断演变，且会因运行的 Kubernetes 版本和集群运行的发行版而有所不同。自定义资源可以用来向集群添加 API 以管理其他类型的对象。例如，KubeVirt 增加了 API 以使 Kubernetes 能够运行虚拟机。可以使用 kubectl api-versions 命令发现特定集群支持的 API 的完整列表。

与 Compose 不同的是，每个对象是在一个单独的 YAML 文档中声明的，尽管可以通过在同一文件中用“—”分隔它们内联多个 YAML 文档，如 Kubernetes 文档中所示。一个复杂的应用程序可能由多个对象组成，其定义分布在多个文件中；在维护此类应用程序时保持所有这些定义同步可能相当繁琐。为了使这项工作更容易，一些 Kubernetes 管理员转向了模板工具如 Jsonnet。

Helm 与应用部署

Helm 进一步推进了模板化的方法。与 Kubernetes 一样，Helm 的开发在 CNCF 的支持下进行；它被誉为“Kubernetes 的包管理器”。Helm 从一组称为 chart 的模板和变量声明集合中生成 Kubernetes 的 YAML 配置。其模板语言与 Ansible 的 Jinja 模板不同，但看起来非常相似；熟悉 Ansible 角色的人可能会对 Helm 图表感到得心应手。

Helm 图表的集合可以在 Helm 存储库中发布；Artifact Hub 提供了一个公共 Helm 存储库的大型目录。管理员可以将这些存储库添加到他们的 Helm 配置中，并使用现成的 Helm 图表将预打包的流行应用程序版本部署到他们的集群。最近版本的 Helm 还支持将图表推送和拉取到容器注册表中，从而为管理员提供了将图表存储在与容器镜像相同位置的选项。

Kubernetes 在短期内没有失去势头的迹象。它被设计为可以管理任何类型的资源；这种灵活性，如通过 KubeVirt 虚拟机控制器所示，即使容器化工作负载最终失宠，它也有可能保持相关性。开发进展迅速，定期发布新版本。版本支持为期一年；似乎没有长期支持版本。支持集群升级，但一些人更愿意建立一个新集群并迁移他们的服务。

Nomad 的简单替代方案

Nomad 是 HashiCorp 推出的编排器，作为 Kubernetes 的简单替代方案进行营销。Nomad 是一个开源项目，像 Docker 和 Kubernetes 一样。它由一个名为 nomad 的二进制文件组成，可用于启动一个称为代理的守护程序，并作为 CLI 与代理进行通信。根据其配置方式，代理进程可以以两种模式之一运行。在服务器模式下运行的代理接受作业并为它们分配集群资源。在客户端模式下运行的代理与服务器联系以接收作业、运行它们，并向服务器报告其状态。代理还可以在开发模式下运行，在这种模式下，它同时承担客户端和服务器的角色，形成一个可用于测试目的的单节点集群。

创建一个 Nomad 集群可能相当简单。在 Nomad 的最基本操作模式下，必须启动初始服务器代理，然后可以使用 nomad server join 命令将其他节点添加到集群中。HashiCorp 还提供了 Consul，这是一种通用服务网格和发现工具。虽然可以单独使用，但 Nomad 与 Consul 结合使用时可能表现最佳。Nomad 代理可以使用 Consul 自动发现和加入集群，并且可以执行健康检查、提供 DNS 记录以及为集群上运行的服务提供 HTTPS 代理。

Nomad 支持复杂的集群拓扑。每个集群分为一个或多个“数据中心”。与 Swarm 类似，单个数据中心内的服务器代理使用一种基于 Raft 的协议进行通信；该协议具有严格的延迟要求，但多个数据中心可以使用一种允许信息在集群中传播的流言协议链接在一起，而无需每个服务器都与每个其他服务器保持直接连接。从用户的角度来看，以这种方式链接在一起的数据中心可以作为一个集群运作。这种架构在扩展到巨大的集群时为 Nomad 带来优势。Kubernetes 官方支持最多 5000 个节点和 300000 个容器，而 Nomad 的文档引用了包含超过 10000 个节点和 200 万个容器的集群示例。

与 Kubernetes 类似，Nomad 不包括容器引擎或运行时。它使用任务驱动程序来运行作业。使用 Docker 和 Podman 运行容器的任务驱动程序已包含在内；社区支持的驱动程序可用于其他容器引擎。同样与 Kubernetes 类似，Nomad 的野心不限于容器；还有其他类型工作负载的任务驱动程序，包括一个简单地在主机上运行命令的 fork/exec 驱动程序、用于运行虚拟机的 QEMU 驱动程序和用于启动 Java 应用程序的 Java 驱动程序。社区支持的任务驱动程序将 Nomad 连接到其他类型的工作负载。

与 Docker 或 Kubernetes 不同，Nomad 避开了 YAML，而是采用 HashiCorp 配置语言（HCL），该语言最初是为另一个 HashiCorp 项目 Terraform 创建的，用于云资源的配置。HCL 在 HashiCorp 产品线中使用广泛，尽管在其他地方采用有限。用 HCL 编写的文档可以轻松转换为 JSON，但其目标是提供比 JSON 更便于手指输入且比 YAML 更不易出错的语法。

HashiCorp 的 Helm 等效工具称为 Nomad Pack。像 Helm 一样，Nomad Pack 处理包含模板和变量声明的目录以生成作业配置。Nomad 还具有一个社区注册表，用于预打包应用程序，但可用选择远少于 Artifact Hub 的 Helm。

Nomad 没有 Kubernetes 那样的受欢迎程度。像 Swarm 一样，其开发似乎主要由其创建者推动；虽然它已被许多大公司部署，但 HashiCorp 仍然是 Nomad 社区的中心。此时，项目似乎不太可能获得足够的动力以独立于其企业母公司存在。用户或许可以从 HashiCorp 更明确地致力于 Nomad 的开发和推广中找到一些保证，这与 Docker 对 Swarm 的承诺形成鲜明对比。

结论

Swarm、Kubernetes 和 Nomad 并不是唯一的容器编排器，但它们是三个最具生命力的工具。Apache Mesos 也可以用于运行容器，但在 2021 年几乎被搁置；基于 Mesos 的 DC/OS 也面临类似的情况，支持其发展的社区和商业实体正在寻找新的方向。尽管如此，Swarm、Kubernetes 和 Nomad 仍然是当前市场上最受欢迎和最活跃的容器编排解决方案，它们各自提供了不同的功能和优势，以满足不同规模和需求的企业。随着技术的不断进步和市场的变化，这些工具将继续演化，以适应未来的挑战和机遇。

如何让 Nacos 支持达梦数据库作为外置数据源

Thu, 23 Nov 2023 05:08:51 +0000

Nacos 支持两种数据持久化方式，一种是利用内置的数据，一种是利用外置的数据源。

内置数据库支持:

Nacos 默认内置了一些数据存储解决方案，如内嵌的 Derby 数据库。
这种内置方式主要用于轻量级或测试环境。

外置数据库支持:

对于生产环境，Nacos 支持外置数据库以提供更高的可靠性和伸缩性。
常见的外置数据库包括 MySQL 等，这些数据库通过标准的 JDBC 接口与 Nacos 集成。

然而达梦数据库 Nacos 原生是不支持的，或者说不能通过简单配置使 Nacos + 达梦数据库这样的组合生效。

达梦数据库是什么

达梦数据库（DMDB），是一款由中国国内团队自主研发的关系型数据库管理系统（RDBMS）。它旨在提供高性能、高可靠性和高安全性的数据库解决方案，特别是对于在政府、金融、电信等行业的应用。

介绍一下达梦数据库的几个关键方面：

自主研发：达梦数据库是由中国国内团队自主研发的，这意味着它在设计和开发过程中更加注重符合国内市场的需求和标准。它的出现也代表了中国在关键技术领域自主创新的重要成果。
高性能：达梦数据库采用了先进的数据库技术，比如高效的存储引擎、智能的查询优化器等，以提供高速的数据处理和查询性能。这使得它适合处理大规模数据和高并发访问，满足企业级应用的需求。
高可靠性：在设计上，达梦数据库强调数据的可靠性和持久性。它提供了严格的事务控制、灾难恢复和备份机制，确保在各种环境下数据的完整性和安全性。
高安全性：达梦数据库特别注重数据安全。它提供了包括数据加密、访问控制、审计日志等多重安全机制，帮助用户防范数据泄露和非法访问。
兼容性和易用性：为了更好地适应现有的企业环境，达梦数据库支持广泛的操作系统和平台，并且与主流的编程语言和开发工具具有良好的兼容性。此外，它还提供了易于使用的管理工具和丰富的文档支持。
应用场景：达梦数据库广泛应用于政府、金融、电信、能源、教育等多个行业，特别是在那些对数据安全性和可靠性有高要求的领域。

为什么使用达梦数据库

在数据库的选型方面，通常我们会使用业内广泛使用的产品，如开源的 MySQL, 甚至收费的如 Oracle、SQL Server，直到 “信创” 的到来，打破了这些传统产品在数据库市场的垄断地位。

“

“信创”这个词最早来源于“信创工委会”。该组织的全称是：信息技术应用创新工作委员会，是在 2016 年，由 24 家专业从事软硬件关键技术研究及应用的国内单位，共同发起成立的一个非营利性社会组织。

”

后来，除了数据安全、网络安全，信创是把之前的一些软硬件等行业放到了一起，重新起了一个名字叫：信息技术应用创新产业，简称“信创”。

也因此，一般来说，信创包括基础硬件、基础软件、应用软件、信息安全四大板块。其中，基础硬件主要包括：芯片、服务器/PC、存储等；基础软件包括：数据库、操作系统、中间件等；应用软件包括：办公软件、ERP 和其它软件等；信息安全包括硬件安全、软件安全、安全服务等各类产品。

针对安全可控，我们国家提出的是“2+8”体系。“2”指党、政；“8”指关于国计民生的八大行业：金融、电力、电信、石油、交通、教育、医疗、航空航天。

发展信创，先在党政等封闭市场进行应用信创产品，打磨产品和生态；接着在产品好用和生态相对成熟之后，进入金融、电力、电信、石油、交通、教育、医疗、航空航天重点行业市场；最后才是将信创产品全面应用到消费市场。

而数据库就是我们常说的 “信创” 四件套（芯片、操作系统、数据库、中间件）之一。达梦数据库就是这样一个符合 “国产化” 要求的自主研发的数据库。所以，由于国家信息安全的要求，我们的客户需要符合这些要求，也必然要进行软件的替换。

实现方案

首先看一下 Nacos 原生支持的外置数据库有哪些，是否支持达梦？

根据以下 Nacos 官方文档，无论是单机还是集群模式，貌似只支持 MySQL 作为外置数据源

只支持 MySQL 吗？不是说还支持其他像 Oracle 之类的数据库吗？

在调研的过程中，发现 github 上 Nacos 的源码有这样一个功能分支 feature_multiple_datasource_support

很明显，它就是用来支持多数据源的，通过源码我们可以看到它支持的多种数据源都有哪些：

这个分支能够支持的外部数据源分别是：

oracle
mysql
postgresql

我分析了 Nacos 1.0 及 2.0 主要版本，发现多数据源的这个功能并没有被合并到主要的开发及 release 分支上。也就是说 Nacos 现有的主要版本的 release 并没有多数据源的这个功能，外置数据源只兼容 MySQL。

根据前面的分析我们知道即使是 feature_multiple_datasource_support 分支也只支持三个数据源，如果想用非 MySQL 的数据源，比如用 Oracle 就需要自己修改和编译源代码。

1mvn -Prelease-nacos -Dmaven.test.skip=true -Dcheckstyle.skip=true clean install -U

具体修改的部分也主要是配置文件 application.properties 没有其他地方了。

Nacos 是支持 Oracle 和 PostgreSQL 的，只不过需要手动修改配置和编译。虽然这种方法可行，但由于功能分支长时间未更新，最新版本的代码未合并过来，可能会造成一些安全和功能上的问题。更重要的是，通过上述的分析我们知道，Nacos 在原生的模式下，确实是不支持达梦数据库的。

方案一修改源代码方式

根据前文我们知道，Nacos 原生是不支持达梦数据库的，所以就要想办法让它 “支持”，直觉上因为是开源软件，我们还是会从源码入手。

既然可以修改源代码，我们就不需要从 feature_multiple_datasource_support 分支开始了，可以在流行的 1.x 、2.x 或最新版本代码的基本上修改。

主要涉及到以下内容的修改：

com/alibaba/nacos/persistence/datasource/ExternalDataSourceProperties.java
console/src/main/resources/application.properties

代码具体的修改方式和内容可以是多样的，下面举几个例子，供参考：

核心思路是：由于达梦数据库良好的支持了 JDBC 驱动，所以我们只需要把 jdbcDriver 进行更换就可以了。然后同样手动进行编译，使用自己编译好的构建物进行部署。

这里涉及到的 Nacos 数据库初始化脚本可以参考：https://gitee.com/tangjingshan/nacos/blob/tjs-study-fetch-master/distribution/conf/dm-schema.sql

总结：

源代码修改方案并不复杂，相对比较简单，但需要做好相关功能的完整测试。
使用这种方式不但可以支持达梦数据库也可以在同样原理下支持其他国产数据库，如 人大金仓
这种方式的问题是由于自行修改了源代码，在进行版本升级时会比较麻烦，每一次升级都要手动合并最新的代码再进行编译，未来甚至有可能出现 Nacos 官方源码进行大规模重构，自行编译的代码无法合并的情况。虽然也有解决办法，但是个麻烦点。
数据迁移，这个后面我具体再详细说明

方案二多数据源插件

Nacos 从 2.2.0 版本开始，可通过 SPI 机制注入多数据源实现插件，它的原理是：

在原来的 Config 模块中，所有的 SQL 操作的执行是通过直接使用 JdbcTemplate 执行固定 SQL 语句的形式，使得 SQL 语句与业务逻辑高度耦合，并且只支持 Derby 与 MySQL 两种数据源，原有 Config 模块架构如下。

现在的多数据源插件通过 SPI 机制，将 SQL 操作按照数据表进行抽象出多个 Mapper 接口，Mapper 接口的实现类需要按照不同的数据源编写对应的 SQL 方言实现；现在插件默认提供 Derby 以及 MySQL 的 Mapper 实现，可直接使用；而其他的数据源则需要用户使用数据源插件进行加载，其改造后架构图如下。

我们这里详细描述一下原理

上图是 Nacos 的源码包中 plugin 模块，可以看到在 datasource 包下有不同的数据库实现类。这里其实就是抽象了 Nacos 操作的各个表的 Mapper 接口实现，你可以看到具体的 SQL 语句都在里面。

既然有 MySQL、derby 的实现，也可以有我们自己的实现，具体来说就是达梦数据库的实现，我们只需要把这几个类重写就可以了，当然具体重写的内容中的 SQL 要根据达梦数据库的方言情况，修改或者不修改。

那么是否可以直接在源码的基础上添加 DM 的实现类进行开发呢？

理论上当然可以，但既然叫插件就有插件的形式。在 Nacos 源码的基础上开发耦合太重了，这不是插件化的表现形式。

我们要把与多数据源相关的自定义代码专门写一个包，然后在 Nacos 的代码中依赖，这样就解耦了，也与上文 Nacos 插件架构图中的描述相符。

插件化是如何实现的呢，或者说动态替换实现类是如何实现的？

这就要利用到 Java 的 SPI 知识了，由于是基础理论这里就不展开讲了。Nacos 在源码中已然利用 SPI 进行数据源 Mapper 的加载了，可以参考下图：

源码位置：com.alibaba.nacos.plugin.datasource.MapperManager#loadInitial

我们可以看到，源码是利用 ServiceLoader 加载插件包，而这些实现类也写在 plugin/datasource/src/main/resources/META-INF/services/com.alibaba.nacos.plugin.datasource.mapper.Mapper 这个文件里

那么如果我们也利用 SPI 配置好 DM 的实现类，然后根据数据源参数找到相应的实现类是不是就可以了？

是的，所以源码中也正是这么做的

源码位置：com.alibaba.nacos.plugin.datasource.MapperManager#findMapper

这里我们讲一下具体的实现方法：

1 初始化达梦数据库，具体脚本可以参考：https://github.com/nacos-group/nacos-plugin/blob/develop/nacos-datasource-plugin-ext/nacos-dm-datasource-plugin-ext/src/main/resources/schema/nacos-dm.sql

2 编写插件包，利用 SPI 的原理，自定义实现各个表的 Mapper 实现类，这里其实 Nacos 的社区 nacos-group 中已经有现成的实现了，可以参考他们的项目和代码，实际上的代码都比较简单，甚至不需要做什么改动，因为基本的 SQL 达梦都是兼容的。

3 插件引入，有两种方式

第一种：

直接用 nacos-group 的现成的实现包，然后用 maven 进行依赖就可以了，例如：

1 <dependency>
2 <groupId>com.alibaba.nacos</groupId>
3 <artifactId>nacos-dm-datasource-plugin-ext</artifactId>
4 <version>1.0.0-SNAPSHOT</version>
5 </dependency>

第二种：

将插件源码打包为 jar 包，将该文件的路径配置到 startup.sh 文件中，使用 Nacos 的 loader.path机制指定该插件的路径，可修改 startup.sh 中的 loader.path 参数的位置进行指定。

启动脚本会指定插件包位置为：-Dloader.path=${BASE_DIR}/plugins loader.path 机制为打包插件 spring-boot-maven-plugin 提供的，该机制下实际启动类会变成org.springframework.boot.loader.PropertiesLauncher#main，且类会由org.springframework.boot.loader.LaunchedURLClassLoader这个类加载器加载

4 修改数据库配置文件，在 application.properties 文件中声明 dameng 的配置信息：

1spring.datasource.platform=dm
2 db.url.0=jdbc:dm://127.0.0.1:5236/DMSERVER?schema=NACOS&compatibleMode=mysql&ignoreCase=true&ENCODING=utf-8
3 db.user.0=SYSDBA
4 db.password.0=SYSDBA
5 db.pool.config.driverClassName=dm.jdbc.driver.DmDriver

5 如果用 maven 依赖的方式引入了插件包，就需要源码重新编译，如果使用 loader.path 指定路径的方式就可以重启进行测试了

数据迁移

无论使用哪种解决方案很大可能性都需要进行数据迁移，即将旧的非达梦数据库的数据迁移到达梦数据库。

我们要把 Nacos 的数据或者 SQL 语句迁移到达梦数据库。借助 DM 数据迁移工具 ，完成 Nacos 配置数据表迁移到达梦数据库。

Make Jar, Not War.

Tue, 05 Jul 2022 09:51:29 +0000

大约在 4 年前，关于 java 应用最终打成 jar 包还是 war 包的选择令我比较疑惑。

那时候更多的应用是打成 war 包的，即使我们知道可以打成 jar 包，但之前都是打成 war 包，并且好像打成 jar 包并没有什么特别明显的好处。

但当时令我困惑的是越来越多的实践正在不怎么说明理由的情况下转而打 jar 包，于是我开始思考……

war 包的理由

在某大型 OTA 企业内部，应用仍然打成 war 包, PaaS 平台会自动安装并配置好 tomcat，我知道这对于 web server 的统一配置和运维来说是有好处的。基于 war 背后的一系列 CI/CD 、DevOps 流程都一定有相应的适配，且就算 jar 包有我不知道的某些优势也不可能一夜之间在大型企业内部使用，需要平台和系统做出调整。

SpringBoot 在当时并未像现在这样流行，这并不意味着大家不用它，我的意思是相对新的项目来说，企业内部会有非常多 “老系统” 需要维护，我们不能指望一下子把这些老系统都用新的技术栈替换掉，就像你知道现在 web application 一般是前后端分离开发，但如果接手一个使用 jsp 的老家伙，你还得维护不是？

jar 的时代

时代不同了，说得好像过了几十年的样子，但其实也就几年光阴而已。不过仅仅是这几年的光阴却足以改变一些事情的面貌。

如今，云原生、微服务大行其道，大家好像已经非常适应这种开发模式，没有人纠结要不要用 SpringBoot，只会讨论使用的版本高还是低。更不用说打包的事情，很自然的会使用 jar,虽然这种看起来的 “最佳实践”，在长期开发的过程中会形成 “肌肉记忆”，但我们还是要讨论一下为什么。

方便

可运行 Jar 是打包自包含可运行应用程序的便捷方法。这样，我们可以最大限度地减少依赖关系。可以通过 Spring boot Maven 和 Gradle plugin 来管理依赖。

云原生友好

在自备容器的情况下（docker,k8s), jar 包可以直接作为一个 single application 来管理。

在过去我们使用 war 是为了让多应用共享 web server，现在是容器的天下，在容器内，一般情况只跑一个应用进程。由于只有一个进程，我们就可以轻松地管理它，比如重启（不会影响其他的应用，因为没有其他应用）。

版本控制

利用 git 等版本控制软件，可以控制程序运行所需要的一切（比如配置文件）

易于扩展

例如，将其复制到另一台服务器，然后“ just run it!” 无需安装和/或配置容器

参考

https://medium.com/@satyajit.nalavade/make-jar-not-war-josh-long-d6ce5fbb8a23

灰度发布、蓝绿部署、金丝雀都是啥？

Tue, 19 Apr 2022 07:13:43 +0000

滚动部署

在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

下图显示了该部署模式：旧版本显示为蓝色，新版本显示为绿色，它们部署在集群中的每一台服务器上。

应用程序套件升级是一个滚动部署的典型例子。如果原始应用部署在容器中，升级可以一次处理一个容器。修改每个容器从应用供应商的站点上下载最新的镜像。如果其中的一个应用存在兼容性问题，旧的镜像可以重新创建这个容器。在这种情况下，套件的新旧版本应用可以共存，直到每个应用都更新完毕。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

蓝绿发布

蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。

蓝绿发布的特点：

在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时间回滚到老版本。

以下示意图可描述灰度发布的大致流程：先切分20%的流量到新版本，若表现正常，逐步增加流量占比，继续测试新版本表现。若新版本一直很稳定，那么将所有流量都切分到新版本，并下线老版本。

切分20%的流量到新版本后，新版本出现异常，则快速将流量切回老版本。

蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

为什么还需要蓝绿

有了灰度发布之后，为什么还需要蓝绿发布呢？主要有如下几点考虑：

应用在生产环境全量发布后，发现故障时回滚时间慢。当线上核心应用存在几十上百的服务实例时，应用实例分批滚动回滚，部分业务应用启动时间需要几分钟，导致整个回滚过程的时间可能超过十分钟，甚至几十分钟。
灰度发布期间能发现的问题有限。如数据库慢查问题、死锁问题等，10%流量很难发现，可能只会在100%流量中才容易暴露。
灰度发布成功后，仍然需要进行全量发布，在此过程中仍有较多不确定性，如因一些未预料的异常导致发布失败等。

对于上面几个问题，使用蓝绿发布系统都可以较好地解决：

蓝绿发布期间，流量全部切至新集群时，原稳定集群继续保持在线，若新集群有问题，可通过流量控制秒级切回至原稳定集群，没有应用启动以及其他等待时间。
蓝绿发布期间，新集群规模与原稳定集群规模一致，即使是瞬时大流量也没有问题。
蓝绿发布期间，新集群承载全站流量，容易验证各种场景，如数据库死锁等并发问题。
蓝绿发布新集群验证完成后，已经处于正常服务状态，不会再引入不确定性的变更操作。

金丝雀发布（canary）

在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。

“

为什么叫金丝雀发布呢，是因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气，这便是金丝雀发布名称的由来。

”

金丝雀发布的特点：

通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。

下图为华为云的金丝雀发布界面：

步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点；

步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）；

步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新

金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。下图示范了金丝雀部署：

金丝雀和蓝绿的对比

名称	特点	优势	劣势
蓝绿部署	同时存在两个集群，两个集群中只有一个集群真正提供服务，另外一个集群测试、验证或待命	服务文档，版本回退简单，适用于各种场景的升级，大版本不兼容升级的或迭代兼容升级	浪费硬件资源，需要同时有两个集群，如果集群比较大，比如有1000个节点，这种方式几乎不可用
金丝雀部署	逐点部署，逐步替换线上服务	小步快跑，快速迭代	只能适用于兼容迭代的方式，如果是大版本不兼容的场景，就没办法使用这种方式了

灰度发布

灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段。

灰度发布，也叫金丝雀发布。是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。

A/B Test

A/B测试和蓝绿发布、滚动发布以及金丝雀发布，完全是两回事。

蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。

实现

kubernetes

官方的金丝雀发布方式

https://kubernetes.io/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments

Deployment滚动更新策略实现金丝雀发布

利用Deployment的滚动更新策略maxSurge和maxUnavailable设置最大可超期望的节点数和最大不可用节点数可实现简单的金丝雀发布。

rollingUpdate.maxSurge最大可超期望的节点数，百分比 10% 或者绝对数值 5

rollingUpdate.maxUnavailable最大不可用节点数，百分比或者绝对数值

 1apiVersion: extensions/v1beta1
 2kind: Deployment
 3metadata:
 4 name: demo-deployment
 5 namespace: default
 6spec:
 7 replicas: 10
 8 selector:
 9 matchLabels:
10 name: hello-deployment
11 strategy:
12 type: RollingUpdate
13 rollingUpdate:
14 maxSurge: 10%
15 maxUnavailable: 0 
16 template:
17 metadata:
18 labels:
19 name: demo-deployment
20 spec:
21 containers:
22 - name: webserver
23 image: nginx:1.14
24 ports:
25 - containerPort:80
26

Ingress-Nginx配置Ingress Annotations实现金丝雀发布

Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的金丝雀发布。Nginx Annotations 支持以下 4 种 Canary 规则：

nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header）一起使用。
nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

注意：金丝雀规则按优先顺序进行如下排序：canary-by-header - > canary-by-cookie - > canary-weight很显然

canary-weight是一种随机策略。

canary-by-cookie和canary-by-header-value适合后端金丝雀发布实现

canary-by-cookie适合前端金丝雀发布实现。

 1apiVersion: extensions/v1beta1
 2kind: Ingress
 3metadata:
 4 name: demo-canary
 5 annotations: 
 6 kubernetes.io/ingress.class: nginx
 7 nginx.ingress.kubernetes.io/canary: "true"
 8 nginx.ingress.kubernetes.io/canary-by-header: "canary"
 9 nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
10spec:
11 rules:
12 - host: demo-api.fulu.com
13 http:
14 paths:
15 - backend:
16 serviceName: demo-api-canary
17 servicePort: 80

具体流程

如果是第一次发布，必须是正常版本。
如果发布金丝雀版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则替换金丝雀版本的镜像，如果没有则创建-canary后缀的ingress、service、deployment。
如果发布正常版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则先删除它们，再替换正常版本的镜像。

蓝绿部署实现： https://www.cnblogs.com/itzgr/p/14602827.html

以上这些方式只是实现了一种非常简单的金丝雀发布流程，是没有办法做更精细，比如说按用户信息去灰度的规则的。对于同一个用户，也有可能一次请求到了金丝雀中，下一次请求又到了正式环境中。假如需要更加精细的灰度规则，可以考虑采用spring cloud, istio等工具

istio

Kubernetes 中的金丝雀部署

假设我们有一个已部署的 helloworld 服务 v1 版本，我们想要测试（或简单上线）新版本 v2。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment] 中的镜像并自动进行部署来[上线]新版本的 helloworld 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停]上线时有足够的 v1 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚]。最好，我们也能够对 Deployment 设置 [HPA]，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。

尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有[公共 pod 标签]的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。

无论我们使用一个或者两个部署，使用 Docker，Mesos/Marathon 或 Kubernetes 等容器编排平台进行的金丝雀发布管理都存在一个根本问题：使用实例扩容来管理流量；版本流量分发和副本部署在上述平台中并独立。所有 pod 副本，无论版本如何，在 kube-proxy 循环池中都被一视同仁地对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比维持金丝雀流量需要许多副本（例如，1％将需要至少 100 个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果我们想根据某些特定规则将请求路由到金丝雀版本上，我们仍然需要另一种解决方案。

使用 Istio，流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩，与版本流量路由的控制完全正交。这在自动缩放的情况下能够更加简单地管理金丝雀版本。事实上，自动缩放管理器仍然独立运行，其在响应因流量路由导致的负载变化与其他原因导致负载变化的行为上没有区别。

Istio 的[路由规则]也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 helloworld 服务的简单便捷。

首先我们定义 helloworld 服务，和普通 Kubernetes 服务一样，如下所示：

 1apiVersion: v1
 2kind: Service
 3metadata:
 4name: helloworld
 5labels:
 6 app: helloworld
 7spec:
 8 selector:
 9 app: helloworld
10 ...
11

然后我们添加 2 个 Deployment，分别为版本 v1 和 v2，这两个版本都包含服务选择标签 app：helloworld

 1kind: Deployment
 2metadata:
 3 name: helloworld-v1
 4spec:
 5 replicas: 1
 6 template:
 7 metadata:
 8 labels:
 9 app: helloworld
10 version: v1
11 spec:
12 containers:
13 - image: helloworld-v1
14 ...
15---
16apiVersion: extensions/v1beta1
17kind: Deployment
18metadata:
19 name: helloworld-v2
20spec:
21 replicas: 1
22 template:
23 metadata:
24 labels:
25 app: helloworld
26 version: v2
27 spec:
28 containers:
29 - image: helloworld-v2
30 ...

需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署]的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。

但是在[启用 Istio] 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％的流量发送到金丝雀版本本，我们可以使用 kubectl 来设置以下的路由规则：

 1kubectl apply -f - <<EOF
 2apiVersion: networking.istio.io/v1alpha3
 3kind: VirtualService
 4metadata:
 5 name: helloworld
 6spec:
 7 hosts:
 8 - helloworld
 9 http:
10 - route:
11 - destination:
12 host: helloworld
13 subset: v1
14 weight: 90
15 - destination:
16 host: helloworld
17 subset: v2
18 weight: 10
19---
20apiVersion: networking.istio.io/v1alpha3
21kind: DestinationRule
22metadata:
23 name: helloworld
24spec:
25 host: helloworld
26 subsets:
27 - name: v1
28 labels:
29 version: v1
30 - name: v2
31 labels:
32 version: v2
33EOF
34

当规则设置生效后，Istio 将确保只有 10% 的请求发送到金丝雀版本，无论每个版本的运行副本数量是多少。

以上是使用istio 进行的金丝雀部署，当然蓝绿也是类似的。

spring cloud

spring cloud gateway也可以实现灰度发布，另外还有一款 spring cloud 的增强组件，可以实现灰度、蓝绿等功能（Discovery: https://github.com/Nepxion/Discovery）

网关

利用云原生网关比如 APISIX ：

https://apisix.apache.org/zh/docs/apisix/plugins/traffic-split/#蓝绿发布
https://apisix.apache.org/zh/docs/apisix/plugins/traffic-split/#灰度发布

参考

我就想存个文件，怎么这么麻烦？- k8s PV、PVC、StorageClass 的关系

Fri, 26 Nov 2021 09:59:13 +0000

Docker

当我们使用 Docker 时，设置数据卷（Volume）还是比较简单的，只需要在容器映射指定卷的路径，然后在容器中使用该路径即可。

比如这种：

 1# tomcat
 2 tomcat01:
 3 hostname: tomcat01
 4 restart: always
 5 image: jdk-tomcat:v8
 6 container_name: tomcat8-1
 7 links:
 8 - mysql:mysql
 9 volumes:
10 - /home/soft/docker/tomcat/webapps:/usr/local/apache-tomcat-8.5.39/webapps
11 - /home/soft/docker/tomcat/logs:/usr/local/apache-tomcat-8.5.39/logs
12 - /etc/localtime:/etc/localtime
13 environment:
14 JAVA_OPTS: -Dspring.profiles.active=prod
15 TZ: Asia/Shanghai
16 LANG: C.UTF-8
17 LC_ALL: zh_CN.UTF-8
18 env_file:
19 - /home/soft/docker/env/tomcat.env

为什么要设置 Volume？当然是因为我们要持久化数据，要把数据存储到硬盘上。

k8s

到了 k8s 这儿，你会发现事情没那么简单了，涌现出了一堆概念：

Pv
Pvc
StorageClass
Provisioner
…

先不管这些复杂的概念，我只想存个文件，有没有简单的方式？

有，我们先回顾下基本概念。

我们知道，Container 中的文件在磁盘上是临时存放的，当容器崩溃时文件丢失。kubelet 会重新启动容器，但容器会以干净的状态重启。所以我们要使用 Volume 来持久化数据。

“

Docker 也有卷（Volume）的概念，但对它只有少量且松散的管理。Docker 卷是磁盘上或者另外一个容器内的一个目录 Docker 提供卷驱动程序，但是其功能非常有限。

”

“

Kubernetes 支持很多类型的卷。Pod 可以同时使用任意数目的卷类型。

”

“

临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。当 Pod 不再存在时，Kubernetes 也会销毁临时卷；不过 Kubernetes 不会销毁持久卷。对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。

”

“

卷的核心是一个目录，其中可能存有数据，Pod 中的容器可以访问该目录中的数据。所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放的内容。

”

“

使用卷时，在 .spec.volumes 字段中设置为 Pod 提供的卷，并在 .spec.containers[*].volumeMounts 字段中声明卷在容器中的挂载位置。各个卷则挂载在镜像内的指定路径上。卷不能挂载到其他卷之上，也不能与其他卷有硬链接。Pod 配置中的每个容器必须独立指定各个卷的挂载位置。

”

通过上面的概念我们知道 Volume 有不同的类型，有临时的，也有持久的，那么我们先说说简单的，即解决“我只想存个文件，有没有简单的方式”的需求。

hostPath

hostPath 卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。看个示例：

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4 name: test-webserver
 5spec:
 6 containers:
 7 - name: test-webserver
 8 image: k8s.gcr.io/test-webserver:latest
 9 volumeMounts:
10 - mountPath: /var/local/aaa
11 name: mydir
12 - mountPath: /var/local/aaa/1.txt
13 name: myfile
14 volumes:
15 - name: mydir
16 hostPath:
17 # 确保文件所在目录成功创建。
18 path: /var/local/aaa
19 type: DirectoryOrCreate
20 - name: myfile
21 hostPath:
22 path: /var/local/aaa/1.txt
23 type: FileOrCreate

通过 hostPath 能够简单解决文件在宿主机上存储的问题。

不过需要注意的是：

HostPath 卷存在许多安全风险，最佳做法是尽可能避免使用 HostPath。当必须使用 HostPath 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。

使用 hostPath 还有一个局限性就是，我们的 Pod 不能随便漂移，需要固定到一个节点上，因为一旦漂移到其他节点上去了宿主机上面就没有对应的数据了，所以我们在使用 hostPath 的时候都会搭配 nodeSelector 来进行使用。

emptyDir

emptyDir 也是比较常见的一种存储类型。

上面的 hostPath 显示的定义了宿主机的目录。emptyDir 类似隐式的指定。

Kubernetes 会在宿主机上创建一个临时目录，这个目录将来就会被绑定挂载到容器所声明的 Volume 目录上。而 Pod 中的容器，使用的是 volumeMounts 字段来声明自己要挂载哪个 Volume，并通过 mountPath 字段来定义容器内的 Volume 目录

“

当 Pod 分派到某个 Node 上时，emptyDir 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。就像其名称表示的那样，卷最初是空的。尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，这些容器都可以读写 emptyDir 卷中相同的文件。当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会被永久删除。

”

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4 name: test-pd
 5spec:
 6 containers:
 7 - image: k8s.gcr.io/test-webserver
 8 name: test-container
 9 volumeMounts:
10 - mountPath: /cache
11 name: cache-volume
12 volumes:
13 - name: cache-volume
14 emptyDir: {}

如果执行 kubectl describe 命令查看 pod 信息的话，可以验证前面我们说的内容：“EmptyDir (a temporary directory that shares a pod’s lifetime)”

 1...
 2Containers:
 3 nginx:
 4 Container ID: docker://07b4f89248791c2aa47787e3da3cc94b48576cd173018356a6ec8db2b6041343
 5 Image: nginx:1.8
 6 ...
 7 Environment: <none>
 8 Mounts:
 9 /usr/share/nginx/html from nginx-vol (rw)
10...
11Volumes:
12 nginx-vol:
13 Type: EmptyDir (a temporary directory that shares a pod's lifetime)

PV 和 PVC

PV(PersistentVolume): 持久化卷
PVC(PersistentVolumeClaim): 持久化卷声明

PV 和 PVC 的关系就像 java 中接口和实现的关系类似。

PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。

PV 是对底层共享存储的一种抽象，由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS、hostPath 等，都是通过插件机制完成与共享存储的对接。

我们来看一个例子：

比如，运维人员可以定义这样一个 NFS 类型的 PV

 1apiVersion: v1
 2kind: PersistentVolume
 3metadata:
 4 name: nfs
 5spec:
 6 storageClassName: manual
 7 capacity:
 8 storage: 1Gi
 9 accessModes:
10 - ReadWriteMany
11 nfs:
12 server: 10.244.1.4
13 path: "/"

PVC 描述的，则是 Pod 所希望使用的持久化存储的属性。比如，Volume 存储的大小、可读写权限等等。

 1
 2apiVersion: v1
 3kind: PersistentVolumeClaim
 4metadata:
 5 name: nfs
 6spec:
 7 accessModes:
 8 - ReadWriteMany
 9 storageClassName: manual
10 resources:
11 requests:
12 storage: 1Gi

用户创建的 PVC 要真正被容器使用起来，就必须先和某个符合条件的 PV 进行绑定。

第一个条件是 PV 和 PVC 的 spec 字段。比如，PV 的存储（storage）大小，就必须满足 PVC 的要求。
第二个条件，则是 PV 和 PVC 的 storageClassName 字段必须一样

在成功地将 PVC 和 PV 进行绑定之后，Pod 就能够像使用 hostPath 等常规类型的 Volume 一样，在自己的 YAML 文件里声明使用这个 PVC 了

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4 labels:
 5 role: web-frontend
 6spec:
 7 containers:
 8 - name: web
 9 image: nginx
10 ports:
11 - name: web
12 containerPort: 80
13 volumeMounts:
14 - name: nfs
15 mountPath: "/usr/share/nginx/html"
16 volumes:
17 - name: nfs
18 persistentVolumeClaim:
19 claimName: nfs

我们前面使用的 hostPath 和 emptyDir 类型的 Volume 并不具备“持久化”特征，既有可能被 kubelet 清理掉，也不能被“迁移”到其他节点上。所以，大多数情况下，持久化 Volume 的实现，往往依赖于一个远程存储服务，比如：远程文件存储（比如，NFS、GlusterFS）、远程块存储（比如，公有云提供的远程磁盘）等等。

StorageClass

前面我们人工管理 PV 的方式就叫作 Static Provisioning。

一个大规模的 Kubernetes 集群里很可能有成千上万个 PVC，这就意味着运维人员必须得事先创建出成千上万个 PV。更麻烦的是，随着新的 PVC 不断被提交，运维人员就不得不继续添加新的、能满足条件的 PV，否则新的 Pod 就会因为 PVC 绑定不到 PV 而失败。在实际操作中，这几乎没办法靠人工做到。所以，Kubernetes 为我们提供了一套可以自动创建 PV 的机制，即：Dynamic Provisioning。

Dynamic Provisioning 机制工作的核心，在于一个名叫 StorageClass 的 API 对象。而 StorageClass 对象的作用，其实就是创建 PV 的模板。

具体地说，StorageClass 对象会定义如下两个部分内容：

第一，PV 的属性。比如，存储类型、Volume 的大小等等。
第二，创建这种 PV 需要用到的存储插件。比如，Ceph 等等。

有了这样两个信息之后，Kubernetes 就能够根据用户提交的 PVC，找到一个对应的 StorageClass 了。然后，Kubernetes 就会调用该 StorageClass 声明的存储插件，创建出需要的 PV。

在下面的例子中，PV 是被自动创建出来的。

 1apiVersion: v1
 2kind: PersistentVolumeClaim
 3metadata:
 4 name: claim1
 5spec:
 6 accessModes:
 7 - ReadWriteOnce
 8# 指定所使用的存储类，此存储类将会自动创建符合要求的 PV
 9 storageClassName: fast
10 resources:
11 requests:
12 storage: 30Gi
13
14apiVersion: storage.k8s.io/v1
15kind: StorageClass
16metadata:
17 name: fast
18provisioner: kubernetes.io/gce-pd
19parameters:
20 type: pd-ssd

StorageClass 的作用，则是充当 PV 的模板。并且，只有同属于一个 StorageClass 的 PV 和 PVC，才可以绑定在一起。StorageClass 的另一个重要作用，是指定 PV 的 Provisioner（存储插件）。这时候，如果你的存储插件支持 Dynamic Provisioning 的话，Kubernetes 就可以自动为你创建 PV 了。

Local PV

Kubernetes 依靠 PV、PVC 实现了一个新的特性，这个特性的名字叫作：Local Persistent Volume，也就是 Local PV。

Local PV 实现的功能就非常类似于 hostPath 加上 nodeAffinity，比如，一个 Pod 可以声明使用类型为 Local 的 PV，而这个 PV 其实就是一个 hostPath 类型的 Volume。如果这个 hostPath 对应的目录，已经在节点 A 上被事先创建好了，那么，我只需要再给这个 Pod 加上一个 nodeAffinity=nodeA，不就可以使用这个 Volume 了吗？理论上确实是可行的，但是事实上，我们绝不应该把一个宿主机上的目录当作 PV 来使用，因为本地目录的存储行为是完全不可控，它所在的磁盘随时都可能被应用写满，甚至造成整个宿主机宕机。所以，一般来说 Local PV 对应的存储介质是一块额外挂载在宿主机的磁盘或者块设备，我们可以认为就是“一个 PV 一块盘”。

Local PV 和普通的 PV 有一个很大的不同在于 Local PV 可以保证 Pod 始终能够被正确地调度到它所请求的 Local PV 所在的节点上面，对于普通的 PV 来说，Kubernetes 都是先调度 Pod 到某个节点上，然后再持久化节点上的 Volume 目录，进而完成 Volume 目录与容器的绑定挂载，但是对于 Local PV 来说，节点上可供使用的磁盘必须是提前准备好的，因为它们在不同节点上的挂载情况可能完全不同，甚至有的节点可以没这种磁盘，所以，这时候，调度器就必须能够知道所有节点与 Local PV 对应的磁盘的关联关系，然后根据这个信息来调度 Pod，实际上就是在调度的时候考虑 Volume 的分布。

例子：

先创建本地磁盘对应的 pv

 1apiVersion: v1
 2kind: PersistentVolume
 3metadata:
 4 name: example-pv
 5spec:
 6 capacity:
 7 storage: 5Gi
 8 volumeMode: Filesystem
 9 accessModes:
10 - ReadWriteOnce
11 persistentVolumeReclaimPolicy: Delete
12 storageClassName: local-storage
13 local:
14 path: /mnt/disks/vol1 
15 nodeAffinity:
16 required:
17 nodeSelectorTerms:
18 - matchExpressions:
19 - key: kubernetes.io/hostname
20 operator: In
21 values:
22 - node-1

其中：

lcal.path 写对应的磁盘路径
必须指定对应的 node , 用 .spec.nodeAffinity 来对应的 node
.spec.volumeMode 可以是 FileSystem（Default）和 Block
确保先运行了 StorageClass （即下面写的文件）

再写对于的 StorageClass 文件

1kind: StorageClass
2apiVersion: storage.k8s.io/v1
3metadata:
4 name: local-storage
5provisioner: kubernetes.io/no-provisioner
6volumeBindingMode: WaitForFirstConsumer

其中：

provisioner 是 kubernetes.io/no-provisioner , 这是因为 local pv 不支持 Dynamic Provisioning, 所以它没有办法在创建出 pvc 的时候，自动创建对应 pv
volumeBindingMode 是 WaitForFirstConsumer , WaitForFirstConsumer 即延迟绑定 , 这样可以既保证推迟到调度的时候再进行绑定 , 又可以保证调度到指定的 pod 上 , 其实 WaitForFirstConsumer 又 2 种：一种是 WaitForFirstConsumer , 一种是 Immediate , 这里必须用延迟绑定模式。

再创建一个 pvc

 1kind: PersistentVolumeClaim
 2apiVersion: v1
 3metadata:
 4 name: example-local-claim
 5spec:
 6 accessModes:
 7 - ReadWriteOnce
 8 resources:
 9 requests:
10 storage: 5Gi
11 storageClassName: local-storage

这里需要注意的地方就是 storageClassName 要写出我们之前自己创建的 storageClassName 的名字：local-storage

之后应用这个文件 , 使用命令 kubectl get pvc 可以看到他的状态是 Pending , 这个时候虽然有了匹配的 pv , 但是也不会进行绑定 , 依然在等待。

之后我们写个 pod 应用这个 pvc

 1kind: Pod
 2apiVersion: v1
 3metadata:
 4 name: example-pv-pod
 5spec:
 6 volumes:
 7 - name: example-pv-storage
 8 persistentVolumeClaim:
 9 claimName: example-local-claim
10 containers:
11 - name: example-pv-container
12 image: nginx
13 ports:
14 - containerPort: 80
15 name: "http-server"
16 volumeMounts:
17 - mountPath: "/usr/share/nginx/html"
18 name: example-pv-storage

这样就部署好了一个 local pv 在 pod 上 , 这样即使 pod 没有了 , 再次重新在这个 node 上创建，写入的文件也能持久化的存储在特定位置。

如何删除这个 pv 一定要按照流程来 , 要不然会删除失败

删除使用这个 pv 的 pod
从 node 上移除这个磁盘（按照一个 pv 一块盘）
删除 pvc
删除 pv

总结

本文我们讨论了 kubernetes 存储的几种类型，有临时存储如：hostPath、emptyDir,也有真正的持久化存储，还讨论了相关的概念，如：PVC、PV、StorageClass等,下图是对这些概念的一个概括：

、

参考

istio 原理简介

Fri, 19 Nov 2021 07:46:22 +0000

前导

由于 istio 自 1.5 版本以后架构上有了较大变化，控制面从多组件变成了单体的 istiod 组件，所以下文会先介绍 1.5 之前的架构，再介绍 1.5 之后的，是一个由繁到简的过程。

istio 1.5 之前架构

Istio 的架构分为控制平面和数据平面

数据平面：由一组智能代理（Envoy）以 sidecar 模式部署，协调和控制所有服务之间的网络通信。
控制平面：负责管理和配置代理路由流量，以及在运行时执行的政策。

可以看到控制面（control plane ）组件众多，下图是 1.1 版本所包含的组件：

istio 工作原理

我们先按照 1.5 版本之前的架构描述

Sidecar 注入 (envoy)

详细的注入过程可以参考：https://blog.yingchi.io/posts/2020/6/istio-sidecar-injection.html

连接（pilot）

控制 && 观测（mixer telemetry、mixer policy）

保护（citadel）

配置

Galley 原来仅负责进行配置验证，1.1 后升级为整个控制面的配置管理中心，除了继续提供配置验证功能外，Galley 还负责配置的管理和分发，Galley 使用网格配置协议 (Mesh Configuration Protocol) 和其他组件进行配置的交互。

提供 istio 中的配置管理服务，验证 Istio 的 CRD 资源的合法性

istio 各组件功能及作用

istio-polit: 服务发现，向数据平面下发规则，包括 VirtualService、DestinationRule、Gateway、ServicEntry 等流量治理规则，也包括认证授权等安全规则。
istio-telemetry: 专门收集遥测数据的 mixer 服务组件。
Istio-policy: 另外一个 mixer 服务，可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行控制。
Istio-citadel: 核心安全组件，提供了自动生成、分发、轮换与撤销秘钥和证书的功能。
Istio-galley: 配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的 Pilot 和 Mixer 使用。
Istio-sidecar-injector: 负责自动注入的组件。
Istio-proxy: 数据面的轻量代理。
Istio-ingressgateway: 入口处的 gateway。

istio 1.5 之后架构

之前版本的 istio 对组件进行了很好的解耦，组件们各司其职，当然也带来了组件比较多的问题。可以看到新版本将众多组件包装在了一起叫 istiod

所以新版本 istio 核心组件就只剩下一个：istiod

参考

Kubernetes监控体系总结

Mon, 15 Nov 2021 12:21:02 +0000

基本概念

cAdvisor

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux/Windows/Mac 机器上。容器镜像正成为一个新的标准化软件交付方式。为了能够获取到 Docker 容器的运行状态，用户可以通过 Docker 的 stats 命令获取到当前主机上运行容器的统计信息，可以查看容器的 CPU 利用率、内存使用量、网络 IO 总量以及磁盘 IO 总量等信息。

显然如果我们想对监控数据做存储以及可视化的展示，那么 docker 的 stats 是不能满足的。

为了解决 docker stats 的问题（存储、展示），谷歌开源的 cadvisor 诞生了，cadvisor 不仅可以搜集一台机器上所有运行的容器信息，还提供基础查询界面和 http 接口，方便其他组件如 Prometheus 进行数据抓取，或者 cAdvisor + influxDB + grafana 搭配使用。cAdvisor 可以对节点机器上的资源及容器进行实时监控和性能数据采集，包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况

监控原理

cAdvisor 使用 Go 语言开发，利用 Linux 的 cgroups 获取容器的资源使用信息，在 K8S 中集成在 Kubelet 里作为默认启动项，官方标配。

Docker 是基于 Namespace、Cgroups 和联合文件系统实现的

Cgroups 不仅可以用于容器资源的限制，还可以提供容器的资源使用率。不管用什么监控方案，底层数据都来源于 Cgroups

Cgroups 的工作目录 /sys/fs/cgroup 下包含了 Cgroups 的所有内容。Cgroups 包含了很多子系统，可以对 CPU，内存，PID，磁盘 IO 等资源进行限制和监控。

cAdvisor 运行原理，如下图

Prometheus

Prometheus 是一套开源的监控报警系统。主要特点包括多维数据模型、灵活查询语句 PromQL 以及数据可视化展示等

架构图

基本原理

Prometheus 的基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口就可以接入监控。不需要任何 SDK 或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如 VM、Docker、Kubernetes 等。输出被监控组件信息的 HTTP 接口被叫做 exporter 。目前互联网公司常用的组件大部分都有 exporter 可以直接使用，比如 Varnish、Haproxy、Nginx、MySQL、Linux 系统信息（包括磁盘、内存、CPU、网络等等）。

服务过程

Prometheus Daemon 负责定时去目标上抓取 metrics（指标）数据，每个抓取目标需要暴露一个 http 服务的接口给它定时抓取。Prometheus 支持通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup 等方式指定抓取目标。Prometheus 采用 PULL 的方式进行监控，即服务器可以直接通过目标 PULL 数据或者间接地通过中间网关来 Push 数据。
Prometheus 在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中。
Prometheus 通过 PromQL 和其他 API 可视化地展示收集的数据。Prometheus 支持很多方式的图表可视化，例如 Grafana、自带的 Promdash 以及自身提供的模版引擎等等。Prometheus 还提供 HTTP API 的查询方式，自定义所需要的输出。
PushGateway 支持 Client 主动推送 metrics 到 PushGateway，而 Prometheus 只是定时去 Gateway 上抓取数据。
Alertmanager 是独立于 Prometheus 的一个组件，可以支持 Prometheus 的查询语句，提供十分灵活的报警方式。

Operator

Operator 是 CoreOS 推出的旨在简化复杂有状态应用管理的框架，它是一个感知应用状态的控制器，通过扩展 Kubernetes API 来自动创建、管理和配置应用实例。

Operator 基于 CustomResourceDefinition(CRD) 扩展了新的应用资源，并通过控制器来保证应用处于预期状态。比如 etcd operator 通过下面的三个步骤模拟了管理 etcd 集群的行为：

通过 Kubernetes API 观察集群的当前状态；
分析当前状态与期望状态的差别；
调用 etcd 集群管理 API 或 Kubernetes API 消除这些差别。

Prometheus Operator

为了在 Kubernetes 能够方便的管理和部署 Prometheus，我们使用 ConfigMap 了管理 Prometheus 配置文件。每次对 Prometheus 配置文件进行升级时，我们需要手动移除已经运行的 Pod 实例，从而让 Kubernetes 可以使用最新的配置文件创建 Prometheus。而如果当应用实例的数量更多时，通过手动的方式部署和升级 Prometheus 过程繁琐并且效率低下。

从本质上来讲 Prometheus 属于是典型的有状态应用，而其又包含了一些自身特有的运维管理和配置管理方式。而这些都无法通过 Kubernetes 原生提供的应用管理概念实现自动化。为了简化这类应用程序的管理复杂度，CoreOS 率先引入了 Operator 的概念，并且首先推出了针对在 Kubernetes 下运行和管理 Etcd 的 Etcd Operator。并随后推出了 Prometheus Operator。

从概念上来讲 Operator 就是针对管理特定应用程序的，在 Kubernetes 基本的 Resource 和 Controller 的概念上，以扩展 Kubernetes api 的形式。帮助用户创建，配置和管理复杂的有状态应用程序。从而实现特定应用程序的常见操作以及运维自动化。

在 Kubernetes 中我们使用 Deployment、DamenSet，StatefulSet 来管理应用 Workload，使用 Service，Ingress 来管理应用的访问方式，使用 ConfigMap 和 Secret 来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件 (Event)，Kubernetes 的 Controller Manager 负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过 Kubernetes 来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

而除了这些原生的 Resource 资源以外，Kubernetes 还允许用户添加自己的自定义资源 (Custom Resource)。并且通过实现自定义 Controller 来实现对 Kubernetes 的扩展。

如下所示，是 Prometheus Operator 的架构示意图：

Prometheus 的本职就是一组用户自定义的 CRD 资源以及 Controller 的实现，Prometheus Operator 负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如 Prometheus Server 自身以及配置的自动化管理工作。

简言之，Prometheus Operator 能够帮助用户自动化的创建以及管理 Prometheus Server 以及其相应的配置。

HPA

Horizontal Pod Autoscaler ，K8S 中的一个概念，可以自动调整 Pod 的数量，以达到指定的目标值。

Pod 水平自动扩缩（Horizontal Pod Autoscaler）可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。除了 CPU 利用率，也可以基于其他应程序提供的 自定义度量指标来执行自动扩缩。Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。

Heapster

Heapster 是容器集群监控和性能分析工具，天然的支持 Kubernetes 和 CoreOS。

Heapster 首先从 K8S Master 获取集群中所有 Node 的信息，然后通过这些 Node 上的 kubelet 获取有用数据，而 kubelet 本身的数据则是从 cAdvisor 得到。所有获取到的数据都被推到 Heapster 配置的后端存储中，并还支持数据的可视化。现在后端存储 + 可视化的方法，如 InfluxDB + grafana。

Heapster 可以收集 Node 节点上的 cAdvisor 数据，还可以按照 kubernetes 的资源类型来集合资源，比如 Pod、Namespace 域，可以分别获取它们的 CPU、内存、网络和磁盘的 metric。默认的 metric 数据聚合时间间隔是 1 分钟。

注意：Kubernetes 1.11 不建议使用 Heapster，就 SIG Instrumentation 而言，这是为了转向新的 Kubernetes 监控模型的持续努力的一部分。仍使用 Heapster 进行自动扩展的集群应迁移到 metrics-server 和自定义指标 API。

Metrics Server

kubernetes 集群资源监控之前可以通过 heapster 来获取数据，在 1.11 开始开始逐渐废弃 heapster 了，采用 metrics-server 来代替，metrics-server 是集群的核心监控数据的聚合器，它从 kubelet 公开的 Summary API 中采集指标信息，metrics-server 是扩展的 APIServer，依赖于 kube-aggregator，因为我们需要在 APIServer 中开启相关参数。

Metrics Server 并不是 kube-apiserver 的一部分，而是通过 Aggregator 这种插件机制，在独立部署的情况下同 kube-apiserver 一起统一对外服务的。

Aggregator

“

通过聚合层扩展 Kubernetes API使用聚合层（Aggregation Layer），用户可以通过额外的 API 扩展 Kubernetes，而不局限于 Kubernetes 核心 API 提供的功能。这里的附加 API 可以是现成的解决方案比如 metrics server, 或者你自己开发的 API。聚合层不同于定制资源（Custom Resources）。后者的目的是让 kube-apiserver 能够认识新的对象类别（Kind）。

”

“

聚合层聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来“申领” Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）转发到已注册的 APIService。

”

“

APIService 的最常见实现方式是在集群中某 Pod 内运行扩展 API 服务器。如果你在使用扩展 API 服务器来管理集群中的资源，该扩展 API 服务器（也被写成“extension-apiserver”）一般需要和一个或多个控制器一起使用。apiserver-builder 库同时提供构造扩展 API 服务器和控制器框架代码。

”

这里，Aggregator APIServer 的工作原理，可以用如下所示的一幅示意图来表示清楚：

因为 k8s 的 api-server 将所有的数据持久化到了 etcd 中，显然 k8s 本身不能处理这种频率的采集，而且这种监控数据变化快且都是临时数据，因此需要有一个组件单独处理他们，于是 metric-server 的概念诞生了。

Metrics server 出现后，新的 Kubernetes 监控架构将变成下图的样子

核心流程（黑色部分）：这是 Kubernetes 正常工作所需要的核心度量，从 Kubelet、cAdvisor 等获取度量数据，再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。
监控流程（蓝色部分）：基于核心度量构建的监控流程，比如 Prometheus 可以从 metrics-server 获取核心度量，从其他数据源（如 Node Exporter 等）获取非核心度量，再基于它们构建监控告警系统。

注意：

metrics-sevrer 的数据存在内存中。
metrics-server 主要针对 node、pod 等的 cpu、网络、内存等系统指标的监控

kube-state-metrics

已经有了 cadvisor、heapster、metric-server，几乎容器运行的所有指标都能拿到，但是下面这种情况却无能为力：

我调度了多少个 replicas？现在可用的有几个？
多少个 Pod 是 running/stopped/terminated 状态？
Pod 重启了多少次？
我有多少 job 在运行中

而这些则是 kube-state-metrics 提供的内容，它基于 client-go 开发，轮询 Kubernetes API，并将 Kubernetes 的结构化信息转换为 metrics。

kube-state-metrics 与 metrics-server 对比

我们服务在运行过程中，我们想了解服务运行状态，pod 有没有重启，伸缩有没有成功，pod 的状态是怎么样的等，这时就需要 kube-state-metrics，它主要关注 deployment,、node 、 pod 等内部对象的状态。而 metrics-server 主要用于监测 node，pod 等的 CPU，内存，网络等系统指标。

metric-server（或 heapster）是从 api-server 中获取 cpu、内存使用率这种监控指标，并把他们发送给存储后端，如 influxdb 或云厂商，他当前的核心作用是：为 HPA 等组件提供决策指标支持。
kube-state-metrics 关注于获取 k8s 各种资源的最新状态，如 deployment 或者 daemonset，之所以没有把 kube-state-metrics 纳入到 metric-server 的能力中，是因为他们的关注点本质上是不一样的。metric-server 仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而 kube-state-metrics 是将 k8s 的运行状况在内存中做了个快照，并且获取新的指标，但他没有能力导出这些指标
换个角度讲，kube-state-metrics 本身是 metric-server 的一种数据来源，虽然现在没有这么做。
另外，像 Prometheus 这种监控系统，并不会去用 metric-server 中的数据，他都是自己做指标收集、集成的（Prometheus 包含了 metric-server 的能力），但 Prometheus 可以监控 metric-server 本身组件的监控状态并适时报警，这里的监控就可以通过 kube-state-metrics 来实现，如 metric-serverpod 的运行状态。

custom-metrics-apiserver

kubernetes 的监控指标分为两种

Core metrics（核心指标）：从 Kubelet、cAdvisor 等获取度量数据，再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。
Custom Metrics（自定义指标）：由 Prometheus Adapter 提供 API custom.metrics.k8s.io，由此可支持任意 Prometheus 采集到的指标。

以下是官方 metrics 的项目介绍：

Resource Metrics API（核心 api）

Heapster
Metrics Server

Custom Metrics API：

Prometheus Adapter
Microsoft Azure Adapter
Google Stackdriver
Datadog Cluster Agent

核心指标只包含 node 和 pod 的 cpu、内存等，一般来说，核心指标作 HPA 已经足够，但如果想根据自定义指标：如请求 qps/5xx 错误数来实现 HPA，就需要使用自定义指标了，目前 Kubernetes 中自定义指标一般由 Prometheus 来提供，再利用 k8s-prometheus-adpater 聚合到 apiserver，实现和核心指标（metric-server) 同样的效果。

HPA 请求 metrics 时，kube-aggregator(apiservice 的 controller) 会将请求转发到 adapter，adapter 作为 kubernentes 集群的 pod，实现了 Kubernetes resource metrics API 和 custom metrics API，它会根据配置的 rules 从 Prometheus 抓取并处理 metrics，在处理（如重命名 metrics 等）完后将 metric 通过 custom metrics API 返回给 HPA。最后 HPA 通过获取的 metrics 的 value 对 Deployment/ReplicaSet 进行扩缩容。

adapter 作为 extension-apiserver（即自己实现的 pod)，充当了代理 kube-apiserver 请求 Prometheus 的功能。

其实 k8s-prometheus-adapter 既包含自定义指标，又包含核心指标，即如果安装了 prometheus，且指标都采集完整，k8s-prometheus-adapter 可以替代 metrics server。

Prometheus 部署方案

prometheus operator

https://github.com/prometheus-operator/prometheus-operator

kube-prometheus

https://github.com/prometheus-operator/kube-prometheus

在集群外部署

https://www.qikqiak.com/post/monitor-external-k8s-on-prometheus/

kube-prometheus 既包含了 Operator，又包含了 Prometheus 相关组件的部署及常用的 Prometheus 自定义监控，具体包含下面的组件

The Prometheus Operator：创建 CRD 自定义的资源对象
Highly available Prometheus：创建高可用的 Prometheus
Highly available Alertmanager：创建高可用的告警组件
Prometheus node-exporter：创建主机的监控组件
Prometheus Adapter for Kubernetes Metrics APIs：创建自定义监控的指标工具（例如可以通过 nginx 的 request 来进行应用的自动伸缩）
kube-state-metrics：监控 k8s 相关资源对象的状态指标
Grafana：进行图像展示

我们的做法

我们的做法，其实跟 kube-prometheus 的思路差不多，只不过我们没有用 Operator ，是自己将以下这些组件的 yaml 文件用 helm 组织了起来而已：

kube-state-metrics
prometheus
alertmanager
grafana
k8s-prometheus-adapter
node-exporter

当然 kube-prometheus 也有 helm charts 由 prometheus 社区提供：https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

这么干的原因是：这样的灵活度是最高的，虽然在第一次初始化创建这些脚本的时候麻烦了些。不过还有一个原因是我们当时部署整个基于 prometheus 的监控体系时，kube-prometheus 这个项目还在早期，没有引起我们的关注。如果在 2021 年年初或 2020 年年底的时候创建的话，可能就会直接上了。

参考

Spring Boot 整合 OpenFeign + Nacos 的坑

Tue, 26 Oct 2021 12:26:36 +0000

Nacos

先在本地部署 Nacos server，然后在 springBoot 项目中添加依赖，理想情况下，服务会自动会注册到注册中心。

环境

SpringBoot 版本：2.3.1.RELEASE
Nacos server 版本：2.0.3
nacos-discovery-spring-boot-starter 版本：0.2.10

Nacos Server

之前用过 Nacos 的 V1 版本，V2 版本没用过，这次用最新版本做个试验。

本地部署 Nacos 没什么问题，我的本地环境是 Mac, 下载好最新的版本 (https://github.com/alibaba/nacos/archive/refs/tags/2.0.3.zip) 解压后，到 bin 目录执行

1sh startup.sh -m standalone

然后浏览器查看 http://localhost:8848/nacos/ 用户名密码都是：nacos

可以看到，我用的版本是 2.0.3

Spring Boot

出问题的地方是在程序中引入的时候，由于要演示 feign 的远程调用，我们分别创建两个项目，provier 和 consumer.

首先创建 provider, 先看下 pom.xml 文件中的依赖，可以看到跟 nacos 相关的只有一个。

 1 <!-- BOM 全局管理 starter 版本 -->
 2 <dependencyManagement>
 3 <dependencies>
 4 <dependency>
 5 <groupId>org.springframework.boot</groupId>
 6 <artifactId>spring-boot-dependencies</artifactId>
 7 <version>${spring-boot-dependencies.version}</version>
 8 <scope>import</scope>
 9 <type>pom</type>
10 </dependency>
11 </dependencies>
12 </dependencyManagement>
13
14 <dependencies>
15
16 <!-- openfeign -->
17 <dependency>
18 <groupId>org.springframework.cloud</groupId>
19 <artifactId>spring-cloud-starter-openfeign</artifactId>
20 <version>${spring-cloud-starter-openfeign.version}</version>
21 </dependency>
22
23 <dependency>
24 <groupId>org.projectlombok</groupId>
25 <artifactId>lombok</artifactId>
26 <version>${lombok.version}</version>
27 <scope>provided</scope>
28 </dependency>
29 <dependency>
30 <groupId>org.springframework.boot</groupId>
31 <artifactId>spring-boot-starter</artifactId>
32 </dependency>
33 <dependency>
34 <groupId>org.springframework.boot</groupId>
35 <artifactId>spring-boot-starter-test</artifactId>
36 <scope>test</scope>
37 </dependency>
38
39 <dependency>
40 <groupId>org.springframework.boot</groupId>
41 <artifactId>spring-boot-starter-web</artifactId>
42 </dependency>
43
44 <dependency>
45 <groupId>com.alibaba.boot</groupId>
46 <artifactId>nacos-discovery-spring-boot-starter</artifactId>
47 <version>0.2.10</version>
48 </dependency>
49
50 <dependency>
51 <groupId>com.google.guava</groupId>
52 <artifactId>guava</artifactId>
53 <version>30.1.1-jre</version>
54 </dependency>
55 </dependencies>

然后再看下 application.yml

 1server:
 2 port: 8080
 3 servlet:
 4 context-path: /provider
 5spring:
 6 mvc:
 7 throw-exception-if-no-handler-found: true # 处理 404 问题
 8 resources:
 9 add-mappings: false # 关闭 404 资源映射
10 application:
11 name: feign-provider
12
13nacos:
14 discovery:
15 server-addr: 127.0.0.1:8848 # Nacos 服务器地址
16

通过官方文档查看，配置比较简单，没什么特殊的。这里强调下，不需要在入口程序 BootstrapApplication 添加什么注解

然后就出问题了，服务死活注册不上去，服务列表一直是空的。

翻阅了各种文档和配置，终于在 github 的 wiki 上找到了官方的说明：https://github.com/nacos-group/nacos-spring-boot-project/wiki

我需要的就是这个：

1# 是否允许服务自动注册（默认为关闭自动注册）
2nacos.discovery.auto-register=true

由于之前用的是 V1 的版本，2 以后的配置没接触过，看来想要自动注册要把这个从 0.2.3 才有的配置加上（我们试验用的 starter 版本是 0.2.10)

以后跟 nacos-discovery-spring-boot-starter 相关版本配置有关的功能，可以参考官方的 wiki：

加上这个配置又丰富了一下后，配置文件变成这样：

 1server:
 2 port: 8080
 3 servlet:
 4 context-path: /provider
 5
 6spring:
 7 mvc:
 8 throw-exception-if-no-handler-found: true # 处理 404 问题
 9 resources:
10 add-mappings: false # 关闭 404 资源映射
11 application:
12 name: feign-provider
13
14nacos:
15 discovery:
16 server-addr: 127.0.0.1:8848 # Nacos 服务器地址
17 auto-register: true # 是否自动注册到 Nacos 中。默认为 false。
18 namespace: # 使用的 Nacos 的命名空间，默认为 null。
19 register:
20 service-name: ${spring.application.name} # 注册到 Nacos 的服务名
21 group-name: DEFAULT_GROUP # 使用的 Nacos 服务分组，默认为 DEFAULT_GROUP。
22

然后就顺利地注册上了：

but

正当我兴冲冲地去写完 consumer 准备消费的时候，却发现怎么也消费不了，google 了个遍，一直都报这个错：

Load balancer does not have available server for client

实在是不想 debug 源码了，消耗完耐心后，决定不用 springBoot 去整合了，还是回到

Spring Cloud + Spring Cloud Alibaba 的路上。

Spring Cloud + Spring Cloud Alibaba

首先要弄清楚版本间的依赖关系，因为版本众多，稍不注意就容易出问题，可以参考这里：

https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E

而 Nacos 的例子，官方有一个直接抄 https://spring-cloud-alibaba-group.github.io/github-pages/hoxton/zh-cn/index.html#%E4%B8%80%E4%B8%AA%E4%BD%BF%E7%94%A8_nacos_discovery%E8%BF%9B%E8%A1%8C%E6%9C%8D%E5%8A%A1%E6%B3%A8%E5%86%8C%E5%8F%91%E7%8E%B0%E5%B9%B6%E8%B0%83%E7%94%A8%E7%9A%84%E4%BE%8B%E5%AD%90

参考完官方的例子后，我的 provider 的 pom.xml 修改如下：

 1 <parent>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-parent</artifactId>
 4 <version>2.3.2.RELEASE</version>
 5 <relativePath/>
 6 </parent>
 7
 8 <properties>
 9 <maven-compiler-plugin.version>3.8.1</maven-compiler-plugin.version>
10 <maven-source.version>3.2.1</maven-source.version>
11 <lombok.version>1.18.12</lombok.version>
12
13 <spring.boot.version>2.3.2.RELEASE</spring.boot.version>
14 <spring.cloud.version>Hoxton.SR9</spring.cloud.version>
15 <spring.cloud.alibaba.version>2.2.6.RELEASE</spring.cloud.alibaba.version>
16
17 </properties>
18
19 <dependencyManagement>
20 <dependencies>
21 <dependency>
22 <groupId>org.springframework.cloud</groupId>
23 <artifactId>spring-cloud-dependencies</artifactId>
24 <version>${spring.cloud.version}</version>
25 <type>pom</type>
26 <scope>import</scope>
27 </dependency>
28 <dependency>
29 <groupId>com.alibaba.cloud</groupId>
30 <artifactId>spring-cloud-alibaba-dependencies</artifactId>
31 <version>${spring.cloud.alibaba.version}</version>
32 <type>pom</type>
33 <scope>import</scope>
34 </dependency>
35 </dependencies>
36 </dependencyManagement>
37
38 <dependencies>
39 <dependency>
40 <groupId>org.springframework.boot</groupId>
41 <artifactId>spring-boot-starter-web</artifactId>
42 </dependency>
43
44 <dependency>
45 <groupId>org.springframework.cloud</groupId>
46 <artifactId>spring-cloud-starter-openfeign</artifactId>
47 </dependency>
48
49 <dependency>
50 <groupId>org.springframework.boot</groupId>
51 <artifactId>spring-boot-starter-actuator</artifactId>
52 </dependency>
53
54 <dependency>
55 <groupId>com.alibaba.cloud</groupId>
56 <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
57 </dependency>
58 </dependencies>

application.yml 修改如下：

 1server:
 2 port: 8080
 3 servlet:
 4 context-path: /provider
 5
 6spring:
 7 mvc:
 8 throw-exception-if-no-handler-found: true # 处理 404 问题
 9 resources:
10 add-mappings: false # 关闭 404 资源映射
11 application:
12 name: feign-provider
13
14 cloud:
15 nacos:
16 discovery:
17 server-addr: 127.0.0.1:8848 # Nacos 服务器地址
18 # namespace: 03afd923-0972-48c4-80fc-69098625d8b0

controller 的接口该怎么写还怎么写，在启动类需要加入一个注解

1@EnableDiscoveryClient

之后把 provider 启动起来，到 nacos 的 dashboard 看一下注册成功了。

接着是 consumer

consumer 的 pom.xml、application.yml 与 provider 一样入口程序同样要加入：

1@EnableDiscoveryClient

feign 接口：

1@FeignClient(name = "feign-provider",path = "/provider")
2public interface ProviderClient {
3
4 @GetMapping("test/hello")
5 String sayHello();
6
7}

controller 消费一下：

 1@RestController
 2@RequestMapping("/test")
 3public class ConsumerController {
 4
 5 @Autowired
 6 private ProviderClient remoteClient;
 7
 8 @GetMapping("/consume")
 9 public String consume() {
10
11 // ServiceInstance serviceInstance = loadBalancerClient.choose("feign-provider");
12 // String url = String.format("http://%s:%s/echo/%s",serviceInstance.getHost(),serviceInstance.getPort(),"feign-provider");
13 // return restTemplate.getForObject(url,String.class);
14
15 return remoteClient.sayHello();
16 }
17
18}

用浏览器请求 consumer 接口测试成功，可以调用到远程 provider 服务。

总结

整体看技术上没什么难度，但 nacos-spring-boot-projec 这个项目直觉上是有坑的，试了许久还是有问题，也许是我没找到问题的根源，所以如果你有耐心可以试着搞搞，如果着急用，还是 Spring Cloud Alibaba 靠谱。

云原生 on 小盒子的技术分享

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

一、 真实的工程世界，从来不是一道“闭卷考试”

二、 刷题面试，正在惩罚真正有经验的“老兵”

三、 算法题面试的本质：一场低效的“智商服从性测试”

四、 如何打破僵局：回归工程本质的面试方法

五、 结语：放过工程师，也放过企业自己

云原生，你真的懂了吗？

啥是云？

“云” 可以有多种形态

资源有啥？

云原生

本质

什么是不可替代的？

云原生的 “复杂性悖论”

结论

云原生应用

什么样的应用是云原生的？

最后

容器编排工具的演进：从 Docker 到 Kubernetes

容器的便利与妥协

Docker Compose 与 Swarm

Kubernetes

Kubernetes 的组成结构

Helm 与应用部署

Nomad 的简单替代方案

结论

如何让 Nacos 支持达梦数据库作为外置数据源

达梦数据库 是什么

为什么使用达梦数据库

实现方案

方案一 修改源代码方式

方案二 多数据源插件

数据迁移

Make Jar, Not War.

war 包的理由

jar 的时代

方便

云原生友好

版本控制

易于扩展

参考

灰度发布、蓝绿部署、金丝雀都是啥？

目录

滚动部署

蓝绿发布

为什么还需要蓝绿

金丝雀发布（canary）

金丝雀和蓝绿的对比

灰度发布

A/B Test

实现

kubernetes

istio

spring cloud

网关

参考

我就想存个文件，怎么这么麻烦 ？- k8s PV、PVC、StorageClass 的关系

Docker

k8s

hostPath

emptyDir

PV 和 PVC

StorageClass

Local PV

总结

参考

istio 原理简介

前导

istio 1.5 之前架构

Istio 的架构分为控制平面和数据平面

istio 工作原理

Sidecar 注入 (envoy)

连接 （pilot）

控制 && 观测 （mixer telemetry、mixer policy）

保护（citadel）

配置

istio 各组件功能及作用

istio 1.5 之后架构

一、真实的工程世界，从来不是一道“闭卷考试”

二、刷题面试，正在惩罚真正有经验的“老兵”

三、算法题面试的本质：一场低效的“智商服从性测试”

四、如何打破僵局：回归工程本质的面试方法

五、结语：放过工程师，也放过企业自己

达梦数据库是什么

方案一修改源代码方式

方案二多数据源插件

我就想存个文件，怎么这么麻烦？- k8s PV、PVC、StorageClass 的关系

连接（pilot）

控制 && 观测（mixer telemetry、mixer policy）