silenceper – 博客

OpenClaw、ZeroClaw、NanoClaw 以及云端 Claw 平台怎么选：一篇给普通人的实用指南

Sun, 08 Mar 2026 12:30:00 +0800

最近一段时间，Claw 类智能体工具越来越多。有人关注 OpenClaw 这样的开源生态型方案，也有人开始尝试 ZeroClaw、NanoClaw 这类更轻量、更可控的自托管路线。同时，腾讯云等云厂商也在推出更易用的智能体平台，让普通用户和业务团队不用自己搭底层系统就能快速上手。

但问题也随之而来：这些工具看起来都能做智能体，普通人到底该怎么选？

这篇文章不打算再花太多篇幅解释 Claw 到底是什么了。毕竟现在大家都在养虾，多少都已经见过这类“能接模型、能调工具、还能帮你干活”的系统。真正值得讲清楚的，不是谁功能最多，而是哪条路线更适合你。

我的核心结论很简单：

想最快上手、最少折腾，优先看云端平台
想要生态活跃、玩法多、适合个人开发，优先看 OpenClaw
想轻量自托管、长期运行，优先看 ZeroClaw
想自己完全掌控系统复杂度，优先看 NanoClaw

如果你只想先看结果，到这里已经够用了。下面再把原因讲透。

为什么 Claw 工具现在反而更难选了

难选的根本原因，不是名字太多，而是这些工具走的根本不是一条路线。

有些方案是本地生态优先，强调插件、社区、玩法和扩展能力；有些方案是轻量部署优先，强调资源占用、隔离边界和长期运行；还有一些则直接把重点放在云端托管、团队协作和业务接入上。

官方宣传通常会强调功能，但普通用户真正关心的问题其实很朴素：

难不难装
难不难配
贵不贵
会不会把自己折腾进运维坑
数据能不能留在本地

所以这篇文章的判断标准也很明确：不比参数堆料，主要看易用性、成本、安全边界、扩展性和适用对象。

先把 Claw 分成 3 类

1. 本地生态型

代表方案：OpenClaw

这一类工具通常有几个明显特征：

社区活跃，资料多，教程也多
可接的能力多，玩法丰富，上手反馈快
很适合个人开发者和喜欢尝鲜的人

它的优点很明显。你想快速体验一个“能跑起来”的智能体系统，通常这类工具最容易给你成就感。很多时候不是它最轻，也不是它最稳，但它往往是最好开始的。

代价也很现实。功能越多，系统边界通常就越大，权限、升级、兼容性和安全配置也更容易变复杂。如果你只是想稳定放在某台机器上长期跑，本地生态型方案未必是最省心的。

2. 轻量自托管型

代表方案：ZeroClaw、NanoClaw

这一类方案的共同点，是尽量把系统做得更轻、更清晰、更可控。

相比生态型工具，它们通常不会把“什么都能接”放在第一位，而是更强调：

部署简单
资源占用低
运行边界清晰
长期维护成本可控

其中，ZeroClaw 更适合偏生产环境、自托管和长期运行场景。它更像是一条“我想把这东西稳定放在服务器、NAS 或边缘设备上持续跑”的路线。

NanoClaw 则更偏向另一种思路：系统尽可能小，源码尽可能容易读懂和改造。它不是为了给所有人提供最多现成功能，而是为了让技术用户能快速掌控整个系统。

3. 云端平台型

代表方案：腾讯云智能体/Agent 平台，以及其他云厂商提供的智能体开发平台

这类方案最核心的卖点，就是省掉大量基础设施工作。

你不需要先部署服务，不需要先管节点、容器、反向代理、权限隔离、升级策略，也不一定要自己从零拼接工作流。对很多普通用户、小团队、业务团队来说，这一点比“是否完全可控”更重要。

云端平台的典型优势是：

开箱即用
模板和集成通常更多
团队协作更方便
从验证想法到上线业务更快

它的代价通常有三类：

长期成本依赖调用量
平台规则和能力边界受厂商影响
数据边界和生态绑定需要提前评估

普通人真正该怎么选

这一部分我直接给结论。

如果你是普通用户

如果你的核心目标是“先用起来”，那就不要先折腾服务器。

对大多数普通用户来说，云端平台通常是更合理的起点。你不需要研究太多底层架构，也不用先补齐运维知识。只要平台的文档清楚、模板够用、接入流程顺，你就能更快判断这类工具到底值不值得继续投入。

这里最容易犯的错误，是一上来就追求“最强方案”。但普通用户真正需要的，往往不是最强，而是最稳定、最容易持续使用的方案。

如果你是个人开发者

个人开发者一般有三种典型诉求：

想快速试各种能力和玩法
想把系统长期跑在自己的机器或小服务器上
想自己改，甚至想完全掌控整个实现

如果你偏第一种，优先看 OpenClaw。它更适合快速验证想法，也更容易接触到丰富的社区经验。

如果你偏第二种，优先看 ZeroClaw。它更适合轻量、稳定、长期运行，不容易把你拖进过重的系统负担。

如果你偏第三种，NanoClaw 会更有吸引力。它不一定最省事，但更适合技术型用户按自己的方式裁剪和改造。

如果你是小团队或企业

小团队和企业做选型时，第一问题其实不是功能，而是数据边界。

如果公司数据可以上云，而且你们的目标是先完成业务验证，那么腾讯云这类云端平台通常是效率更高的路线。它能让团队更快做出可演示、可试用、可验证价值的 Agent 应用。

如果数据不能上云，或者你们明确需要私有化、边缘部署、长期稳定运行，那么就应该优先考虑 ZeroClaw 这类更偏自托管和生产部署的路线。

至于 NanoClaw，它更适合有较强工程能力、希望最小化系统复杂度、并且愿意自己承担更多工程实现工作的团队。

一张表看懂四类方案

维度	OpenClaw	ZeroClaw	NanoClaw	腾讯云等云端平台
上手难度	中	中	中到高	低
部署方式	本地/自托管	本地/自托管	本地/容器优先	云端托管
易用性	强	中上	中	很强
资源占用	中到高	低	低	本地压力低
安全边界	依赖版本和配置	相对清晰	更强调最小化	依赖平台能力和配置
生态与模板	强	中	较弱	强
自定义能力	强	强	强，但更工程化	中到强，取决于平台开放度
运维成本	中到高	中	中	低
长期成本	低到中	低到中	低到中	中到高
适合谁	尝鲜者、个人开发者	自托管、生产部署	技术型用户、小团队	普通用户、业务团队

如果你更在意“开箱即用”，表里最值得看的其实是上手难度、易用性和运维成本。

如果你更在意“长期可控”，那就重点看安全边界、部署方式和长期成本。

每一种路线，分别适合什么人

OpenClaw：适合“先跑起来，再逐步扩展”的人

OpenClaw 的优势通常不在于最轻，而在于最容易形成正反馈。

你能快速把一个可用系统搭起来，也更容易从社区里找到示例、教程、模板和排错经验。对于个人开发者、内容创作者、独立产品尝试者来说，这种“先能跑，再优化”的体验非常重要。

但它的问题也同样明显：随着功能和集成能力越来越多，系统复杂度往往会上升。你需要更关注版本变化、权限配置、依赖更新以及升级策略。它适合快试、快做、快扩展，但未必天然适合所有长期稳定部署场景。

ZeroClaw：适合“想稳、想省资源、想长期运行”的人

ZeroClaw 的核心卖点是轻量和可控。

如果你希望把系统长期放在自己的服务器、NAS、家用设备或者边缘节点上稳定运行，那么这类方案往往更有吸引力。它不一定有最花哨的生态，但通常能给你更可预测的部署体验和更清晰的运行边界。

对于工程读者来说，它更像是一条偏生产环境的路线：不是为了玩具化体验，而是为了在成本、资源和可维护性之间取得平衡。

NanoClaw：适合“想尽量简单、想完全掌控”的人

NanoClaw 更像是极简主义路线。

它适合那些不想要一个“大而全”平台，而是更想得到一个“小而清晰”基础骨架的人。对于能读源码、愿意自己加功能、也愿意自己承担维护责任的工程师或小团队来说，这种方案很有吸引力。

它的优势是结构简单、改造直接、理解成本低。它的不足也很直接：生态、模板和开箱即用能力，通常不如更成熟、更重的项目。

腾讯云等云端平台：适合“先用起来，再决定要不要自建”的人

云端平台的最大优势，不是绝对性能，而是效率。

如果你是业务团队、产品经理、运营人员，或者是没有专门基础设施能力的小团队，那么云端平台通常是最省时间的路线。它特别适合做业务验证、内部助手、知识库问答、流程连接、客服类 Agent 这类场景。

如果你的目标是尽快接企业知识库、流程系统、客服系统或者内部服务，云端平台通常能让你少走很多基础设施弯路。

但一定要单独评估两件事：

长期成本是否可接受
平台绑定是否会影响未来迁移

很多团队前期上云很顺，真正开始扩量后，才发现成本和边界才是后半程的关键变量。

普通人最容易忽略的 5 个坑

1. 把“功能多”误当成“更适合自己”

功能多不一定是好事。功能越多，学习成本和配置复杂度通常也越高。很多人最后不是输在不会用 AI，而是输在系统太重，根本懒得继续维护。

2. 只看演示，不看部署和维护

演示视频里三分钟跑通，不代表你自己部署也能三分钟跑通。真正应该看的是：

有没有清晰文档
有没有现成模板
遇到问题有没有明确排错路径

3. 只看首月成本，不看长期成本

自托管看起来便宜，但需要你自己负责维护。云端平台上手很快，但调用量增长后，成本不一定比自托管低。

选型时最好把“未来三个月到一年”的使用量和维护投入一起算，而不是只看第一周能不能免费跑起来。

4. 忽略数据边界

如果系统会接入公司文档、客户资料、代码仓库或者业务数据，那么“能不能上云”往往比“功能是否更多”更重要。这个问题应该在一开始问，而不是等系统接好以后再问。

5. 忽略安全和版本问题

Claw/Agent 类系统天然拥有更高权限。它们可能会读文件、执行脚本、连接内部系统，风险并不等同于普通聊天工具。

所以选型时最好明确看三件事：

项目是否持续维护
升级路径是否清楚
权限和安全说明是否明确

可以直接照抄的选型结论

如果你只需要一句话版本，可以直接这么记：

想最快上手、资料多、社区活跃：选 OpenClaw
想轻量自托管、长期稳定运行：选 ZeroClaw
想系统尽量简单、自己可控：选 NanoClaw
想低门槛、少运维、快速落地：选腾讯云等云端平台

如果你更喜欢按场景来判断，可以直接这样看：

普通用户：优先云端平台
个人开发者：优先 OpenClaw
想低资源部署：优先 ZeroClaw
想深度改造：优先 NanoClaw
企业业务验证：优先云端平台
企业私有化和长期生产部署：优先轻量自托管路线

最后一句

不存在适合所有人的 Claw。

真正好的选型，不是追求功能最多，而是选择最符合自己成本、安全边界和维护能力的方案。对大多数普通人来说，先从易用的云端平台开始，再决定是否迁移到本地或自托管，通常是更稳妥的路径。

如果你已经很明确自己会长期使用、需要更强控制力、或者数据不能上云，那就不要被“开箱即用”迷惑，直接看轻量自托管路线，反而更省时间。

告别"上下文爆炸"：AI Skills 带来的上下文管理革命

Mon, 19 Jan 2026 00:00:00 +0800

在 AI Agent（智能体）的开发中，我们经常面临一个两难困境：想让 AI 处理复杂的项目，必须提供足够的信息；但如果把整个项目代码或数据库都塞进 Prompt，不仅 Token 费用惊人，还会迅速撑爆模型的上下文窗口（Context Window），导致 AI “变笨"或遗忘。

Skills（技能）正是为了解决这个问题而生。它不仅仅是给 AI 装上双手，更重要的是给 AI 一个“按需索取"的过滤器，让 AI 能够主动检索、精准操作，而不是被动接收海量数据。

1. 核心痛点：为什么我们需要 Skills 来省 Token？

传统模式：Context Stuffing（上下文填充）

在没有 Skills 之前，如果你想让 AI 修复一个 Bug，你可能需要把整个文件夹的代码复制粘贴给它。

后果：

费用高：输入 10 万行代码可能消耗几十美元
效果差：大量无关信息（噪音）干扰 AI 的注意力，导致幻觉
不可行：如果你的数据库有 1TB 数据，你根本无法塞进 Prompt

进化模式：Skills（动态检索）

有了 Skills，AI 变身为一个"主动调查员”。它不再被动接收庞大的数据投喂，而是拥有了检索工具。

场景对比：

假设你要在一个包含 1000 个文件的项目中找一个变量定义的错误。

没有 Skills：你需要把 1000 个文件全部喂给 AI（Token 爆炸）
有 Skills（如 grep_search, read_file）：
1. AI 思考：“我需要先找一下这个变量在哪里”
2. AI 调用 grep_search Skill → 消耗极少 Token
3. Skills 返回 3 个相关文件路径
4. AI 调用 read_file 只读取这 3 个文件 → 只消耗这 3 个文件的 Token
5. AI 解决问题

结论：Skills 将"全量数据处理"变成了"精准数据交互”，Token 消耗可能降低 90% 以上。

2. 图解：Skills 如何优化 Token 流量

我们可以通过数据流向图来直观对比：

graph TD
subgraph "传统方式: 上下文填充"
DB[整个数据库/所有代码] -->|全部通过 Context 传输 (巨大 Token 消耗)| LLM1[AI 模型]
LLM1 -->|处理过载| Result1[结果: 往往不准确]
end
subgraph "新方式: Skills 动态检索"
LLM2[AI 模型] -->|1. 仅发送查询指令 (极小 Token)| Skill[Skill: 搜索/查询]
DB2[整个数据库/所有代码] -- 过滤 --> Skill
Skill -->|2. 仅返回相关的那几行数据 (少量 Token)| LLM2
LLM2 -->|精准处理| Result2[结果: 精准且便宜]
end
style DB fill:#ffcccc
style DB2 fill:#ccffcc
style Skill fill:#ffffcc

3. Skills 的三大核心优势

除了降低 Token，Skills 还有什么不可替代的优点？

优势一：无限的"虚拟上下文"（Infinite Context）

这是 Skills 最大的优点。虽然现在的模型（如 Claude 3、GPT-4）支持 128k 甚至更多上下文，但依然有限。通过 Skills（如数据库查询、搜索引擎、文件系统访问），AI 实际上连接到了无限的外部存储。AI 不需要"记住"所有维基百科的内容，它只需要"拥有"搜索维基百科的 Skill。

优势二：数据的实时性（Freshness）

大模型的知识是静止的（训练截止日期）。Skills 是动态的。

例子：模型不知道今天英伟达的股价，但 fetch_stock_price Skill 知道
价值：让 AI 从"历史学家"变成了"实时分析师"

优势三：副作用与行动力（Agency）

这是从"读"到"写"的跨越。Skills 允许 AI 对现实世界产生影响（Side Effects）。

不仅仅是建议代码，而是直接 write_file 到磁盘
不仅仅是写邮件草稿，而是通过 API send_email 发送出去

4. 总结

Skills 的引入，本质上是一场**“上下文管理的革命”**。

它不再强迫用户去"筛选信息"喂给 AI，而是把这个筛选的权利交给了 AI 自己。

以前：用户手动从海量数据中人肉检索 → 喂给 AI → AI 处理
现在：用户给指令 → AI 利用 Skills 低成本试错、检索、验证 → AI 解决问题

这不仅让 AI 变得更聪明（拥有实时数据和行动力），更关键的是，它让复杂的 AI 应用在**成本（Token）和规模（上下文长度）**上变得真正可行。

随着开源 Skills 生态系统的不断成熟，我们有理由相信，未来的 AI Agent 将更加智能、高效，能够处理更复杂的任务，同时保持合理的成本。

收集Vibe Coding 的AI工具集合

Thu, 08 Jan 2026 00:00:00 +0800

日常开发中已经离不开AI工具，我创建了一个GitHub仓库，用于收集Vibe Coding 的AI工具集合，欢迎大家一起维护，目前收集的工具如下：

Vibe Coding AI Tools

免费体验 Google AI 图片生成神器：Nano Banana Pro 完整教程

Sun, 30 Nov 2025 00:00:00 +0800

简介

Google Cloud Platform (GCP) 为新用户提供了 300 美元的免费试用额度，可以用来体验各种 Google Cloud 服务。本文将详细介绍如何利用这个免费试用额度来使用 Google AI Studio 中的 Nano Banana Pro 模型。

Nano Banana Pro 是 Google 推出的轻量级 AI 模型，适合快速原型开发和实验。通过本文的步骤，你可以免费体验这个强大的 AI 模型。

前提条件

在开始之前，请确保你具备以下条件：

一个 Google 账号
一张有效的信用卡（用于验证身份，不会在免费试用期间扣费）
能够访问 Google Cloud Platform 和 Google AI Studio

详细步骤

步骤 1：访问 Google AI Studio

首先，访问 Google AI Studio，使用你的 Google 账号登录。

步骤 2：创建新项目并设置账单

在左侧导航栏中，点击 Dashboard
选择 Projects
点击 Create a New Project
输入项目名称（例如：Free300API）
点击 Setup billing 设置账单

步骤 3：填写信用卡以及地址信息

地区选择美国，通过用https://www.meiguodizhi.com/ 生成一个美国地址，然后填写到账单设置页面。在账单设置页面，填写你的信用卡信息。这是 Google 用于验证身份的方式，在免费试用期间（300 美元额度内）不会产生任何费用。

注意：确保你的信用卡信息正确，Google 可能会进行小额验证（通常会在验证后立即退还）。

步骤 4：启动免费试用

完成信用卡验证后，前往 Google Cloud Console
在控制台中，找到并点击 启动免费使用 或 Start Free Trial 按钮
确认激活 300 美元的免费试用额度

步骤 5：创建 API Key

返回 Google AI Studio
在左侧导航栏中，点击 Dashboard
选择 API Keys
点击 Create API Keys 创建新的 API 密钥
选择你刚才创建的项目（例如：Free300API）
复制生成的 API Key（请妥善保管，不要泄露）

步骤 6：在 Playground 中链接 API Key

在左侧导航栏中，点击 Playground
选择 Nano Banana Pro 模型
点击 Link API Keys 或 链接 API Keys
选择刚才创建的 API Key

步骤 7：开始使用 Nano Banana Pro

完成以上步骤后，你就可以在 Playground 中免费使用 Nano Banana Pro 模型了。你可以在输入框中输入提示词，与模型进行交互。

使用效果展示

以下是通过 Nano Banana Pro 生成的一些示例效果：

提示词：电影级史诗镜头，一名未来超级战士站在废墟中，全身正在被黑色的纳米液态金属迅速覆盖，六边形蜂巢结构的装甲正在自动组装与闭合，装甲缝隙中流动着高亮的青色能量电流，极其精细的机械纹理，微观视角下可见无数微小的纳米机器人在工作，体积光，火花飞溅，丁达尔效应，超写实，8k分辨率，虚幻引擎5渲染，压迫感，赛博朋克风格。

注意事项

免费额度限制：300 美元的免费试用额度通常有效期为 90 天，请在有效期内使用。
超出额度：如果超出免费额度，Google 会按照标准费率收费。建议在 Google Cloud Console 中设置预算提醒。
API Key 安全：请妥善保管你的 API Key，不要将其提交到公开的代码仓库中。
地区限制：某些地区可能无法使用 Google Cloud 服务，请确认你所在地区的可用性。

常见问题

Q: 免费试用期间会扣费吗？
A: 在 300 美元免费额度内不会扣费，但需要绑定信用卡进行身份验证。

Q: 免费试用额度用完后怎么办？
A: 你可以选择升级到付费账户继续使用，或者在 Google Cloud Console 中设置预算限制以避免意外费用。

Q: API Key 可以用于其他项目吗？
A: 可以，你可以在多个项目中使用同一个 API Key，但建议为不同项目创建不同的 API Key 以便管理。

总结

通过以上步骤，你可以轻松利用 GCP 的 300 美元免费试用额度来体验 Nano Banana Pro 模型。这是一个很好的机会来探索和测试 Google 的 AI 服务，而无需承担任何费用（在免费额度内）。

如果你在使用过程中遇到任何问题，可以参考 Google AI Studio 官方文档或 Google Cloud 支持中心。

参考资料

AI辅助开发小程序的实践分享

Wed, 26 Nov 2025 00:00:00 +0000

背景

没写过前端，只写过后端主要熟悉的语言是golang，完成这个小程序主要分为了以下几个阶段：

需求分析

通过 Google AI Studio 中的gemini进行规划进行需求分析以及列出详细的需求说明；这个小程序的主要功能主要是进行万能的记录类应用，同时我也给出了几个同类的APP让它进行分析；包括名字也是它给取的

最后得到如下的项目介绍，当然还有其他的一些项目的描述（这里没有记录下来）

# 星轨纪 (Star Trace)
> 记录点滴，看见轨迹 ✨
## 📖 项目理念
**星**：是您记录下的每一个数据点
**轨**：是时间将这些星点串联成的生命轨迹
**纪**：是我们为您铭记并呈现这一切
生命如繁星点点，每一次体重测量、每一粒服下的药丸、每一餐精心的饮食，都是您生命星图中闪烁的光点。时间如织，将这些星点串联成轨迹，勾勒出您的健康图景、生活节奏与成长轨迹。
**星轨纪** 是一个基于灵活事件模板系统的数据追踪微信小程序，致力于帮助您：
- 🌟 **记录每一颗星** - 轻松捕捉生活中的每个数据点
- 🛤️ **绘制生命轨迹** - 用时间串联起零散的记录
- 📚 **铭记成长历程** - 将数据转化为有意义的洞察
无论是健康管理、习惯养成，还是生活记录，星轨纪都能成为您忠实的数字伙伴。

AI编码

编码我用的是vscode 中的copilot；

为了能够让AI能够进行完全的全栈式的编写，后端也一起放在同一个仓库了，分为了backend和miniprogram目录。

我指定了技术栈，后端使用golang+gin+gorm的方式，前端使用tdesign库保证美观。


## 后端项目结构
backend/
├── cmd/ # 命令行工具
│ ├── server/ # API 服务器
│ ├── migrate/ # 数据库迁移
│ └── gen/ # GORM Gen 代码生成
├── pkg/ # 核心包
│ ├── handler/ # 请求处理器
│ ├── middleware/ # 中间件
│ ├── config/ # 配置管理
│ ├── db/ # 数据库连接和迁移
│ ├── models/ # 数据模型
│ ├── dal/ # 数据访问层（自动生成）
│ └── response/ # 统一响应格式
├── docs/ # 文档
├── scripts/ # 脚本文件
├── examples/ # 示例代码
├── Dockerfile # Docker 镜像构建
├── docker-compose.yml # Docker 编排
├── Makefile # 构建脚本
└── go.mod # Go 模块定义
## 前端项目结构
miniprogram/
├── app.js # 应用入口
├── app.json # 全局配置
├── app.wxss # 全局样式
├── theme.wxss # TDesign 主题定制
├── pages/ # 页面文件夹
│ ├── dashboard/ # 首页（事件快捷入口）
│ ├── timeline/ # 记录时间线
│ ├── charts/ # 数据分析图表
│ ├── profile/ # 个人中心
│ └── templates/ # 模板管理（新增）
├── utils/ # 工具函数
│ ├── storage.js # 数据存储管理
│ └── util.js # 通用工具函数
└── custom-tab-bar/ # 自定义底部导航

当然在实现的过程中还要不断地调教，不过最后实现的效果还可以，用的越多发现要时不时的切换新的会话，不然会“降智”，我基本用的是CLaude Sonnet4模型。

最后放几个效果图：

在Claude Code中使用DeepSeek v3.1模型：完整指南

Thu, 21 Aug 2025 00:00:00 +0000

DeepSeek v3.1 模型介绍

DeepSeek v3.1 于 2025 年 8 月 21 日发布，是在 V3 基础上的重要升级，具有以下核心特性：

混合推理架构：同一模型支持“非思考模式”和“思考模式”，分别对应 deepseek-chat 与 deepseek-reasoner，便于在速度与推理深度间灵活取舍。
128K 上下文长度：更长上下文，适合代码库分析、长文档处理与多文件协作。
思考效率提升：在思维链压缩后，V3.1-Think 用更少的 tokens 达到与 R1-0528 近似的效果。
工具与智能体能力增强：在代码修复（SWE）与复杂终端任务（Terminal-Bench）上显著提升，更适合工具调用/多步任务。
Function Calling（strict）支持：Beta 接口支持严格模式，确保函数输出满足 schema（详见官方文档）。
Anthropic API 兼容：可直接以 Anthropic API 形式接入 Claude Code 与其生态。

参考：

DeepSeek V3.1 发布说明：DeepSeek V3.1 发布 2025/08/21

Claude Code 安装指南

系统要求

macOS、Windows 或 Linux 系统
Node.js 16+ 版本
稳定的网络连接

安装步骤

下载 Claude Code
- 访问 Claude Code 官网下载对应版本的安装包
- 或者通过 npm 安装：
```
npm install -g @anthropic-ai/claude-code
```

在 Claude Code 中配置 DeepSeek v3.1

按照 Anthropic API 兼容规范，Claude Code 只需设置以下环境变量即可切换到 DeepSeek 模型：

设置环境变量（临时会话）

# DeepSeek 提供的 Anthropic 兼容入口
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic

# 使用 DeepSeek 的 API Key（Claude Code 读取 ANTHROPIC_AUTH_TOKEN）
export ANTHROPIC_AUTH_TOKEN="${DEEPSEEK_API_KEY}"

# 默认主模型（非思考模式）
export ANTHROPIC_MODEL=deepseek-chat

# 快速小模型（同样可设为 deepseek-chat）
export ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat

若希望在 Claude Code 中启用“思考模式”，将 ANTHROPIC_MODEL 改为：

export ANTHROPIC_MODEL=deepseek-reasoner

提示：上述方式仅对当前 shell 会话生效。若需长期生效，可将这些 export 行加入 ~/.zshrc 或 ~/.bashrc。

启动与验证

cd your-project
claude

启动后，Claude Code 将读取环境变量并使用 DeepSeek 模型。你可以直接在命令行对话进行代码协作与修改。若需确认模型，查看启动日志或在会话中询问当前模型配置。

更多兼容细节与字段支持矩阵，参考官方文档：Anthropic API 指南。

常见问题与注意事项

模型与模式选择：
- deepseek-chat：非思考模式，响应更短更快。
- deepseek-reasoner：思考模式，适合复杂多步推理场景。
上下文长度：V3.1 API 默认支持 128K 上下文，适合长文档/多文件协作。
工具调用与函数：支持 tools 与 tool_choice（none/auto/any/tool）。Beta 接口支持 strict Function Calling 以保证输出符合 schema（以官方文档为准）。
字段兼容性要点：
- temperature（0.0~2.0）、max_tokens、system、stream 均支持。
- thinking 字段在兼容模式下被忽略；图片/文档/搜索结果等部分复杂 message 类型暂不支持。
Tokenizer/模板差异：V3.1 对分词器与 chat template 有较大调整，与 V3 存在差异，迁移前请阅读新版说明。

参考：

发布说明：DeepSeek V3.1 发布 2025/08/21
兼容说明：Anthropic API 指南

参考资料

DeepSeek 官方文档 · 新闻：DeepSeek V3.1 发布 2025/08/21
DeepSeek 官方文档 · 指南：Anthropic API

Windows-MCP：让AI直接操作你的Windows系统

Fri, 15 Aug 2025 00:00:00 +0000

项目信息

项目名称	Windows-MCP
开源协议	MIT License
GitHub Stars	2k+
项目地址	https://github.com/CursorTouch/Windows-MCP
所属公司	CursorTouch
支持系统	Windows 7/8/8.1/10/11
编程语言	Python

演示视频

什么是Windows-MCP？

Windows-MCP 是一个轻量级的开源项目，它作为MCP（Model Context Protocol）服务器，在AI代理和Windows操作系统之间架起了一座桥梁。通过这个工具，AI代理可以直接与Windows系统交互，执行各种自动化任务。

核心特性

🎯 无缝Windows集成

与Windows UI元素原生交互
打开应用程序、控制窗口
模拟用户输入操作
支持文件导航和管理

🤖 支持任意LLM

与许多自动化工具不同，Windows-MCP不依赖传统的计算机视觉技术或特定的微调模型。它可以使用任何LLM，降低了复杂性和设置时间。

🛠️ 丰富的UI自动化工具集

基础键盘和鼠标操作
窗口/UI状态捕获
实时交互（典型延迟0.7-2.5秒）

🔧 轻量级和可扩展

最小依赖
易于设置
完全开源（MIT许可证）
可根据需求自定义和扩展

支持的MCP工具

Windows-MCP提供了以下工具来与Windows交互：

Click-Tool: 在指定坐标点击屏幕
Type-Tool: 在元素上输入文本（可选择清除现有文本）
Clipboard-Tool: 使用系统剪贴板复制或粘贴
Scroll-Tool: 在窗口或特定区域垂直或水平滚动
Drag-Tool: 从一个点拖拽到另一个点
Move-Tool: 移动鼠标指针
Shortcut-Tool: 按下键盘快捷键（Ctrl+c、Alt+Tab等）
Key-Tool: 按下单个键
Wait-Tool: 暂停指定时间
State-Tool: 获取默认语言、浏览器、活动应用程序和交互式、文本和可滚动元素的组合快照，以及桌面截图
Resize-Tool: 更改应用程序的窗口大小或位置
Launch-Tool: 从开始菜单启动应用程序
Shell-Tool: 执行PowerShell命令
Scrape-Tool: 抓取整个网页信息

系统要求

前置条件

Python 3.13+
Anthropic Claude Desktop应用或其他MCP客户端
UV（包管理器），通过pip install uv安装
DXT（桌面扩展），通过npm install -g @anthropic-ai/dxt安装
Windows默认语言为英语，或禁用MCP服务器中的Launch-Tool和Resize-Tool

快速开始

Gemini CLI集成

在文件资源管理器中导航到%USERPROFILE%/.gemini并打开settings.json
在settings.json中添加windows-mcp配置并保存：

{
 "theme": "Default",
 "mcpServers": {
 "windows-mcp": {
 "command": "uv",
 "args": [
 "--directory",
 "<windows-mcp目录的路径>",
 "run",
 "main.py"
 ]
 }
 }
}

在终端中重新运行Gemini CLI，开始使用！

Claude Desktop集成

克隆仓库：

git clone https://github.com/CursorTouch/Windows-MCP.git
cd Windows-MCP

构建桌面扩展DXT：

npx @anthropic-ai/dxt pack

打开Claude Desktop：
- 进入设置 -> 扩展 -> 安装扩展（定位.dxt文件）-> 安装

实际应用场景

自动化测试

应用程序UI测试
功能验证
回归测试

工作流程自动化

文件处理
应用程序操作
数据录入

远程控制

通过SSH远程操作电脑
移动设备控制桌面
跨平台任务执行

注意事项

⚠️ 安全提醒

此MCP直接与Windows操作系统交互以执行操作。请谨慎使用，避免在无法承受此类风险的环境中部署。

📝 当前限制

在段落中选择特定文本部分（正在开发中）
Type-Tool主要用于输入文本，不适合在IDE中编程（正在开发中）

总结

Windows-MCP为AI代理提供了与Windows系统深度集成的能力，开启了AI自动化操作的新时代。无论是日常任务自动化、应用程序测试，还是远程系统管理，Windows-MCP都提供了强大而灵活的工具集。

随着AI技术的不断发展，这类工具将变得越来越重要，为个人和企业用户提供更高效的工作方式。如果你对AI自动化感兴趣，Windows-MCP绝对值得一试！

如何使用Golang开发MCP服务器：从mcp-go到mcp-k8s实践

Sat, 19 Apr 2025 09:00:00 +0800

随着大语言模型(LLM)与开发工具的深度融合，Model Control Protocol (MCP)协议正在成为AI与软件工具交互的重要桥梁。MCP允许LLM以结构化的方式调用工具，使AI能够执行具体的操作而不仅仅是生成文本。

本文将详细介绍如何使用Golang和mcp-go这个SDK来开发MCP服务器，并以我的开源项目mcp-k8s为具体案例，讲解如何构建一个与Kubernetes集群交互的MCP服务器。

MCP协议简介

MCP (Model Control Protocol)是一种协议，允许LLM与外部工具进行结构化交互。通过MCP，LLM可以：

获取可用工具及其参数列表
调用这些工具执行操作
获取操作结果并基于结果继续交互

这使得LLM能够"控制"外部系统，执行从查询数据库到操作Kubernetes资源等各种任务。

mcp-go SDK概述

mcp-go是一个用Golang实现的MCP协议SDK，它提供了构建MCP服务器所需的核心组件：

工具注册和管理
协议消息处理
多种传输方式支持（stdio、HTTP SSE等）

使用mcp-go，我们可以快速构建自己的MCP服务器，而无需关心底层协议细节。

开发MCP服务器的基本步骤

使用mcp-go开发MCP服务器通常包括以下步骤：

设计并定义工具（Tools）
实现工具的具体功能
创建服务器并注册工具
配置并启动服务器

下面我们将详细介绍每一步。

1. 设计并定义工具

在MCP中，工具（Tool）是LLM可以调用的功能单元。每个工具需要定义：

名称（Name）：工具的标识符
描述（Description）：工具的功能描述
参数（Parameters）：工具接受的参数及其类型
处理函数（Handler）：实现工具功能的函数

以mcp-k8s中的get_api_resources工具为例：

// 定义工具
var getAPIResourcesTool = server.Tool{
 Name: "get_api_resources",
 Description: "获取集群中所有支持的API资源类型",
 Parameters: nil, // 此工具不需要参数
 Handler: handleGetAPIResources,
}

// 实现处理函数
func handleGetAPIResources(ctx context.Context, rawParams json.RawMessage) (interface{}, error) {
 // 具体实现...
}

2. 实现工具的具体功能

工具的Handler函数实现具体的业务逻辑。在mcp-k8s中，这些函数主要与Kubernetes API交互。

例如，获取API资源列表的实现：

func handleGetAPIResources(ctx context.Context, rawParams json.RawMessage) (interface{}, error) {
 // 创建k8s discovery客户端
 discoveryClient, err := discovery.NewDiscoveryClientForConfig(kubeConfig)
 if err != nil {
 return nil, fmt.Errorf("创建discovery客户端失败: %w", err)
 }

 // 获取服务器上所有API组
 apiGroups, err := discoveryClient.ServerGroups()
 if err != nil {
 return nil, fmt.Errorf("获取API组失败: %w", err)
 }

 // 处理结果并返回
 result := processAPIGroups(apiGroups)
 return result, nil
}

3. 创建服务器并注册工具

使用mcp-go创建MCP服务器并注册工具：

func main() {
 // 创建MCP服务器
 s, err := server.NewServer(
 server.WithLogger(log.Default()),
 )
 if err != nil {
 log.Fatalf("创建服务器失败: %v", err)
 }

 // 注册工具
 s.RegisterTool(getAPIResourcesTool)
 s.RegisterTool(getResourceTool)
 s.RegisterTool(listResourcesTool)
 // ... 注册更多工具

 // 启动服务器
 if err := s.Start(); err != nil {
 log.Fatalf("启动服务器失败: %v", err)
 }
}

4. 配置并启动服务器

mcp-go支持多种传输方式，最常用的是stdio（标准输入/输出）和SSE（Server-Sent Events）。

// stdio模式（默认）
s, err := server.NewServer(
 server.WithLogger(log.Default()),
 server.WithTransport(server.TransportStdio),
)

// SSE模式
s, err := server.NewServer(
 server.WithLogger(log.Default()),
 server.WithTransport(server.TransportSSE),
 server.WithHost("localhost"),
 server.WithPort(8080),
)

mcp-k8s: 一个完整的实践案例

mcp-k8s是一个使用mcp-go开发的、用于与Kubernetes集群交互的MCP服务器。它提供了以下工具：

资源类型查询工具
- get_api_resources: 获取集群中所有支持的API资源类型
资源操作工具
- get_resource: 获取特定资源的详细信息
- list_resources: 列出某种资源类型的所有实例
- create_resource: 创建新资源（可配置禁用）
- update_resource: 更新现有资源（可配置禁用）
- delete_resource: 删除资源（可配置禁用）

以下是mcp-k8s的核心实现：

目录结构

mcp-k8s/
├── cmd/
│ └── server/
│ └── main.go # 主程序入口
├── internal/
│ ├── config/ # 配置处理
│ ├── k8s/ # Kubernetes客户端
│ └── tools/ # MCP工具实现
├── go.mod
└── go.sum

主程序入口

// cmd/server/main.go
func main() {
 // 解析命令行参数
 kubeconfig := flag.String("kubeconfig", "", "Kubernetes配置文件路径")
 enableCreate := flag.Bool("enable-create", false, "启用资源创建操作")
 enableUpdate := flag.Bool("enable-update", false, "启用资源更新操作")
 enableDelete := flag.Bool("enable-delete", false, "启用资源删除操作")
 transport := flag.String("transport", "stdio", "传输方式: stdio或sse")
 host := flag.String("host", "localhost", "SSE模式的主机名")
 port := flag.Int("port", 8080, "SSE模式的端口")
 flag.Parse()

 // 初始化Kubernetes客户端
 if err := k8s.InitClient(*kubeconfig); err != nil {
 log.Fatalf("初始化K8s客户端失败: %v", err)
 }

 // 创建MCP服务器
 serverOpts := []server.Option{
 server.WithLogger(log.Default()),
 }

 // 配置传输方式
 if *transport == "sse" {
 serverOpts = append(serverOpts,
 server.WithTransport(server.TransportSSE),
 server.WithHost(*host),
 server.WithPort(*port),
 )
 } else {
 serverOpts = append(serverOpts, server.WithTransport(server.TransportStdio))
 }

 s, err := server.NewServer(serverOpts...)
 if err != nil {
 log.Fatalf("创建服务器失败: %v", err)
 }

 // 注册工具
 tools.RegisterTools(s, &tools.Options{
 EnableCreate: *enableCreate,
 EnableUpdate: *enableUpdate,
 EnableDelete: *enableDelete,
 })

 // 启动服务器
 if err := s.Start(); err != nil {
 log.Fatalf("启动服务器失败: %v", err)
 }
}

工具实现示例

以get_resource工具为例：

// internal/tools/get_resource.go
var GetResourceTool = server.Tool{
 Name: "get_resource",
 Description: "获取特定资源的详细信息",
 Parameters: []server.Parameter{
 {
 Name: "apiVersion",
 Description: "资源的API版本",
 Type: "string",
 Required: true,
 },
 {
 Name: "kind",
 Description: "资源类型",
 Type: "string",
 Required: true,
 },
 {
 Name: "name",
 Description: "资源名称",
 Type: "string",
 Required: true,
 },
 {
 Name: "namespace",
 Description: "资源所在的命名空间（如适用）",
 Type: "string",
 Required: false,
 },
 },
 Handler: handleGetResource,
}

type GetResourceParams struct {
 APIVersion string `json:"apiVersion"`
 Kind string `json:"kind"`
 Name string `json:"name"`
 Namespace string `json:"namespace"`
}

func handleGetResource(ctx context.Context, rawParams json.RawMessage) (interface{}, error) {
 var params GetResourceParams
 if err := json.Unmarshal(rawParams, &params); err != nil {
 return nil, fmt.Errorf("解析参数失败: %w", err)
 }

 // 获取动态客户端
 dynamicClient, err := k8s.GetDynamicClient()
 if err != nil {
 return nil, err
 }

 // 获取资源GVR (Group Version Resource)
 gvr, namespaced, err := k8s.GetGVR(params.APIVersion, params.Kind)
 if err != nil {
 return nil, err
 }

 // 确定是命名空间级别还是集群级别的资源
 var object *unstructured.Unstructured
 if namespaced {
 // 如果是命名空间级别资源但未提供命名空间，使用默认命名空间
 namespace := params.Namespace
 if namespace == "" {
 namespace = "default"
 }
 object, err = dynamicClient.Resource(gvr).Namespace(namespace).Get(ctx, params.Name, metav1.GetOptions{})
 } else {
 object, err = dynamicClient.Resource(gvr).Get(ctx, params.Name, metav1.GetOptions{})
 }

 if err != nil {
 return nil, fmt.Errorf("获取资源失败: %w", err)
 }

 return object.Object, nil
}

注册所有工具

// internal/tools/tools.go
type Options struct {
 EnableCreate bool
 EnableUpdate bool
 EnableDelete bool
}

func RegisterTools(s *server.Server, opts *Options) {
 // 注册查询工具（始终启用）
 s.RegisterTool(GetAPIResourcesTool)
 s.RegisterTool(GetResourceTool)
 s.RegisterTool(ListResourcesTool)

 // 根据配置注册写操作工具
 if opts.EnableCreate {
 s.RegisterTool(CreateResourceTool)
 }
 if opts.EnableUpdate {
 s.RegisterTool(UpdateResourceTool)
 }
 if opts.EnableDelete {
 s.RegisterTool(DeleteResourceTool)
 }
}

使用方法

mcp-k8s支持两种通信模式：

1. Stdio模式（默认）

在stdio模式下，mcp-k8s通过标准输入/输出流与客户端通信。

// MCP客户端配置
{
 "mcpServers": {
 "mcp-k8s": {
 "command": "/path/to/mcp-k8s",
 "args": [
 "-kubeconfig", "/path/to/kubeconfig",
 "-enable-create",
 "-enable-delete",
 "-enable-update"
 ]
 }
 }
}

2. SSE模式

在SSE模式下，mcp-k8s暴露HTTP端点供MCP客户端连接。

# 运行SSE模式服务
./bin/mcp-k8s -kubeconfig=/path/to/kubeconfig -transport=sse -port=8080 -host=localhost -enable-create -enable-delete -enable-update

// MCP客户端配置
{
 "mcpServers": {
 "mcp-k8s": {
 "url": "http://localhost:8080/sse",
 "args": []
 }
 }
}

MCP服务开发的最佳实践

基于开发mcp-k8s的经验，我总结了以下开发MCP服务的最佳实践：

工具命名与分类：使用清晰、一致的命名方式，按功能分类工具
参数设计：参数名称要直观，提供清晰的描述，明确标记必选参数
安全控制：对写操作提供独立的开关控制，避免不必要的权限风险
错误处理：返回详细的错误信息，帮助LLM理解失败原因
状态管理：MCP服务应保持无状态，所有必要信息通过参数传递
文档完善：详细记录每个工具的功能、参数和使用示例

结论

使用Golang和mcp-go SDK开发MCP服务器是一个相对简单的过程。通过定义和实现工具，我们可以让LLM具备与各种系统交互的能力，从而大大扩展其应用场景。

mcp-k8s项目展示了如何构建一个功能完整的MCP服务器，让LLM能够查询、创建、更新和删除Kubernetes资源，为集群管理提供了新的交互方式。

希望本文能够帮助你理解MCP协议和使用Golang开发MCP服务器的基本方法。更多详情，欢迎访问mcp-k8s项目，或查看mark3labs/mcp-go的文档。

参考资料

AI&&MCP交流群

我建了一个"AI技术交流群"，目的是为了方便大家交流AI相关的知识和共享资源，目前AI变化真的是太快了，如果二维码失效大家关注公众号"AI技术小林"，发送关键字”加群“，拉你进去，；

MCP-K8s：当AI成为我的Kubernetes小助手

Thu, 03 Apr 2025 22:20:59 +0800

还记得刚开始接触Kubernetes时的感受吗？复杂的架构、繁多的概念、以及那些需要记忆的kubectl命令…，现在有了MCP可以让这种交互变得更加简单，尝试通过AI自然语言对话来完成对k8s集群各种资源的操作乃至于定于集群的问题。

它是怎么工作的？

说起来很简单，MCP-K8s就像是在Kubernetes和AI之间搭了一座桥。通过MCP（Model Control Protocol）协议，它能让AI理解你的自然语言指令，并转换成对应的Kubernetes操作。

要用起来也超级简单，只需要在Cursor中配置一下：

{
 "mcpServers": {
 "mcp-k8s": {
 "command": "/path/to/mcp-k8s",
 "args": [
 "-kubeconfig",
 "/path/to/kubeconfig",
 "-enable-create",
 "-enable-delete",
 "-enable-update"
 ]
 }
 }
}

实战体验

来看看实际用起来是什么感觉：

查询集群信息

比如我想看看集群节点情况，直接问就好了：

查询k8s版本

创建资源

需要创建新资源？就像跟同事说话一样描述你的需求：

AI会帮你处理好所有细节：

最终效果如下：

模拟排障

这个是我最喜欢的部分。有一次我故意搞了个问题，有一个pod没有running：

只需要简单说明情况：

mcp-demo 命名空间下有个nginx 的pod没有running，看下是什么原因并解决

在这个过程中AI会自动调用mcp 工具，并将查询到的结果提交给大模型进行分析，分析之后进行定位并解决

个人想法

这里不得不夸一下Claude模型，感觉它特别能够理解mcp的tool，每次都能够精准的知道应该传入那种参数。虽然在tool定义中都有描述，但是对比了其他的一些模型和mcp server的交互，总是不尽人意，要不就是给的参数json格式错误，要不就是理解错了参数需要传入的信息。

技术点分享

说实话，能把这个项目做出来，主要归功于：

AI理解能力: 特别是Claude这样的模型，对上下文的理解真的很到位
参数处理: AI能自动推断出正确的参数，这个太省心了
问题诊断: 它不是简单地执行命令，而是真的能理解问题并给出解决方案

未来畅想

说实话，现在的功能还只是冰山一角。我觉得未来可以做的事情还有很多：

智能运维: 让AI不只是执行命令，还能主动发现和预防问题
运维自动化: 通过简单的对话完成复杂的运维流程
经验沉淀: 把每次排障的经验都变成AI的知识，越用越智能

写在最后

做这个项目的过程中，最大的感受就是：技术发展真的太快了，AI给我们带来了太多可能性。虽然现在还有很多可以改进的地方，但我相信这只是开始。期待看到更多人加入进来，一起把Kubernetes运维变得更简单、更智能。

如果你也对这个项目感兴趣，欢迎来GitHub看看，一起讨论，一起改进。

xfsquota：一个便捷的管理xfs磁盘配额的命令行工具

Sat, 23 Apr 2022 22:20:59 +0800

源码地址：https://github.com/silenceper/xfsquota

动机

在Linux有一个xfs_quota（在xfsprogs工具包下）命令行工具，为什么还用golang实现了？

主要是要因为最近要实现磁盘quota的控制，同时觉得看了docker内的源码，都是利用cgo的方式来实现的，如果直接用xfs_quota的方式查看配额，无法直观的看到某一个目录下的配额，只能列出所有，并且没有具体目录，类似如下结果，在设置了docker 容器的quota之后查看每个容器的配额，只有Project ID无法判别到具体某个目录：

 # xfs_quota -x -c "report" /data
 Project quota on /data (/dev/vdb)
 Blocks
Project ID Used Soft Hard Warn/Grace
---------- --------------------------------------------------
#0 7394256 0 0 00 [--------]
#2 8 52428800 52428800 00 [--------]
#3 8 52428800 52428800 00 [--------]
#4 8 52428800 52428800 00 [--------]
#5 2360 52428800 52428800 00 [--------]
#6 8 52428800 52428800 00 [--------]
#7 8 52428800 52428800 00 [--------]
#8 8 52428800 52428800 00 [--------]
#9 10568 52428800 52428800 00 [--------]
#10 0 52428800 52428800 00 [--------]
#11 0 52428800 52428800 00 [--------]
#12 0 52428800 52428800 00 [--------]
#13 0 52428800 52428800 00 [--------]
#14 0 52428800 52428800 00 [--------]
#15 0 52428800 52428800 00 [--------]
#16 0 52428800 52428800 00 [--------]
#17 0 52428800 52428800 00 [--------]
#18 0 52428800 52428800 00 [--------]
#19 0 52428800 52428800 00 [--------]

所有用cgo的方式，可以实现对某个目录的quota查看。

主要功能

support set quota
support get quota
clean quota

Usage

xfsquota is a tool for managing XFS quotas

Usage:
 xfsquota [command]

Available Commands:
 clean clean quota information
 completion Generate the autocompletion script for the specified shell
 get Get quota information
 help Help about any command
 set Set quota information
 version get version

Flags:
 -h, --help help for xfsquota

Use "xfsquota [command] --help" for more information about a command.

Set Quota

set quota size 1MiB ,inodes 20 for path /data/test/quota

> xfsquota set /data/test/quota -s 1MiB -i 20

set quota success, path: /data/test/quota, size:1MiB, inodes:20

Get Quota

get quota for path /data/test/quota

> xfsquota get /data/test/quota

quota Size(bytes): 1048576
quota Inodes: 20
diskUsage Size(bytes): 0
diskUsage Inodes: 1

Clean Quota

xfsquota clean /data/test/quota

emptyDir 通过xfs_quota 强制限制大小

Sat, 30 Oct 2021 23:20:59 +0800

emptyDir支持三种类型的，通过设置 medium 字段：

文件：默认情况
Memory：占用内存资源
HugePages

sizeLimit默认行为

同时支持通过sizeLimit设置限制的大小，但是这个大小默认情况下(LocalStorageCapacityIsolation 特性默认开启)并不是强制限制的，而是由eviction manager 扫描到超过设定的大小之后，再将pod进行驱逐，所以存在一种情况就是文件其实已经超过了限定的大小(可能已经影响到了系统上其他服务)，而驱逐是定时触发的，有一定的时间间隔。

我们希望能够达到强制的效果的话，就需要做一些hack。

通过xfs quota 限制

kubelet root-dir 使用xfs文件系统，并附上 project quota 属性，例如： /dev/vdb /data xfs noatime,prjquota 1 2
node上 xfs_quota 工具使用较新版本，需要支持 -f 参数

其实在 k8s 1.15增加了一个特性 LocalStorageCapacityIsolationFSQuotaMonitoring (PR：https://github.com/kubernetes/kubernetes/pull/66928) ，这个特性就是通过XFS quotas来给kubelet目录设置配额，但是这里仅仅只是监控消耗，并没有强制限制，可以看下这段代码：

https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/util/fsquota/quota_linux.go#L342-L343

func AssignQuota(m mount.Interface, path string, poduid types.UID, bytes *resource.Quantity) error {
.....
 //这里强制设置成了-1 表示无限制
 if ibytes > 0 {
 ibytes = -1
 }
 if err = setQuotaOnDir(path, id, ibytes); err == nil {
 quotaPodMap[id] = poduid
 quotaSizeMap[id] = ibytes
 podQuotaMap[poduid] = id
 dirQuotaMap[path] = id
 dirPodMap[path] = poduid
 podDirCountMap[poduid]++
 klog.V(4).Infof("Assigning quota ID %d (%d) to %s", id, ibytes, path)
 return nil
 }
 removeProjectID(path, id)
 }
 return fmt.Errorf("assign quota FAILED %v", err)
}

hack

将其中 ibytes > 0 判断改为 ibytes ≤ 0 即，setQuota的时候将sizeLimit设置进去，就可以达到强制限制的效果。

测试一下：

pod.yaml

apiVersion: v1
kind: Pod
metadata:
 labels:
 app: nginx
 name: pod-test
 namespace: default
spec:
 containers:
 - args:
 - "100000"
 command:
 - sleep
 image: nginx
 imagePullPolicy: IfNotPresent
 name: nginx
 volumeMounts:
 - name: data-test
 mountPath: /data/test/
 volumes:
 - name: data-test
 emptyDir:
 sizeLimit: "50Mi"

进入pod中写入文件测试：

root@pod-test:/data/test# dd if=/dev/zero of=./bigfile bs=1M count=2000
dd: error writing './bigfile': No space left on device
51+0 records in
50+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0573529 s, 914 MB/s

达到我们的预期。

参考

https://kubernetes.io/zh/docs/concepts/storage/volumes/#emptydir

csi-driver-host-path安装

Sat, 28 Nov 2020 15:40:59 +0800

集群 v1.19.0

安装

https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/docs/deploy-1.17-and-later.md

VolumeSnapshot CRDs and snapshot controller installation


# Apply VolumeSnapshot CRDs version:v2.0.1
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v2.0.1/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v2.0.1/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v2.0.1/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
# Create snapshot controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v2.0.1/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v2.0.1/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

Deployment

代码地址：https://github.com/kubernetes-csi/csi-driver-host-path

sh deploy/kubernetes-latest/deploy.sh

安装成功：

➜ ~ kubectl get pod|grep csi
csi-hostpath-attacher-0 1/1 Running 0 76m
csi-hostpath-provisioner-0 1/1 Running 0 76m
csi-hostpath-resizer-0 1/1 Running 1 76m
csi-hostpath-snapshotter-0 1/1 Running 0 76m
csi-hostpath-socat-0 1/1 Running 0 76m
csi-hostpathplugin-0 3/3 Running 1 76m
my-csi-app 1/1 Running 0 46m

因为验证而已，这里csi-hostpathplugin组件只部署了一个，provisioner和attacher组件都会调用这个组件上来

验证

部署测试应用，storageClass,pvc,app:

$ for i in ./examples/csi-storageclass.yaml ./examples/csi-pvc.yaml ./examples/csi-app.yaml; do kubectl apply -f $i; done
storageclass.storage.k8s.io/csi-hostpath-sc created
persistentvolumeclaim/csi-pvc created
pod/my-csi-app created

查看pv已自动创建出来了

$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e 1Gi RWO Delete Bound default/csi-pvc csi-hostpath-sc 50m

$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
csi-pvc Bound pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e 1Gi RWO csi-hostpath-sc 50m

在节点上的/var/lib/csi-hostpath-data/目录下已经有目录创建出来了

可以通过查看容器csi-hostpathplugin-0 的log来看整个pv的创建以及attach过程：

I1116 06:54:50.518286 1 server.go:117] GRPC call: /csi.v1.Controller/CreateVolume
I1116 06:54:50.518384 1 server.go:118] GRPC request: {"accessibility_requirements":{"preferred":[{"segments":{"topology.hostpath.csi/node":"minikube"}}],"requisite":[{"segments":{"topology.hostpath.csi/node":"minikube"}}]},"capacity_range":{"required_bytes":1073741824},"name":"pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e","volume_capabilities":[{"AccessType":{"Mount":{}},"access_mode":{"mode":1}}]}
I1116 06:54:50.581056 1 controllerserver.go:165] created volume 9f684dbc-27d8-11eb-884a-0242ac120016 at path /csi-data-dir/9f684dbc-27d8-11eb-884a-0242ac120016
I1116 06:54:50.581129 1 server.go:123] GRPC response: {"volume":{"accessible_topology":[{"segments":{"topology.hostpath.csi/node":"minikube"}}],"capacity_bytes":1073741824,"volume_id":"9f684dbc-27d8-11eb-884a-0242ac120016"}}
I1116 06:54:52.020457 1 server.go:117] GRPC call: /csi.v1.Identity/Probe
I1116 06:54:56.879104 1 server.go:117] GRPC call: /csi.v1.Node/NodeGetCapabilities
I1116 06:54:56.879169 1 server.go:118] GRPC request: {}
I1116 06:54:56.879866 1 server.go:123] GRPC response: {"capabilities":[{"Type":{"Rpc":{"type":1}}},{"Type":{"Rpc":{"type":3}}}]}
I1116 06:54:57.020014 1 server.go:117] GRPC call: /csi.v1.Node/NodeStageVolume
I1116 06:54:57.020087 1 server.go:118] GRPC request: {"staging_target_path":"/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/globalmount","volume_capability":{"AccessType":{"Mount":{}},"access_mode":{"mode":1}},"volume_context":{"storage.kubernetes.io/csiProvisionerIdentity":"1605508257344-8081-hostpath.csi.k8s.io"},"volume_id":"9f684dbc-27d8-11eb-884a-0242ac120016"}
I1116 06:54:57.022399 1 server.go:123] GRPC response: {}
I1116 06:54:57.041971 1 server.go:117] GRPC call: /csi.v1.Node/NodeGetCapabilities
I1116 06:54:57.042036 1 server.go:118] GRPC request: {}
I1116 06:54:57.043319 1 server.go:123] GRPC response: {"capabilities":[{"Type":{"Rpc":{"type":1}}},{"Type":{"Rpc":{"type":3}}}]}
I1116 06:54:57.068101 1 server.go:117] GRPC call: /csi.v1.Node/NodePublishVolume
I1116 06:54:57.068159 1 server.go:118] GRPC request: {"staging_target_path":"/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/globalmount","target_path":"/var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount","volume_capability":{"AccessType":{"Mount":{}},"access_mode":{"mode":1}},"volume_context":{"csi.storage.k8s.io/ephemeral":"false","csi.storage.k8s.io/pod.name":"my-csi-app","csi.storage.k8s.io/pod.namespace":"default","csi.storage.k8s.io/pod.uid":"9c5aa371-e5a7-4b67-8795-ec7013811363","csi.storage.k8s.io/serviceAccount.name":"default","storage.kubernetes.io/csiProvisionerIdentity":"1605508257344-8081-hostpath.csi.k8s.io"},"volume_id":"9f684dbc-27d8-11eb-884a-0242ac120016"}
I1116 06:54:57.104975 1 mount_linux.go:164] Detected OS without systemd
I1116 06:54:57.146159 1 nodeserver.go:166] target /var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount
fstype
device
readonly false
volumeId 9f684dbc-27d8-11eb-884a-0242ac120016
attributes map[csi.storage.k8s.io/ephemeral:false csi.storage.k8s.io/pod.name:my-csi-app csi.storage.k8s.io/pod.namespace:default csi.storage.k8s.io/pod.uid:9c5aa371-e5a7-4b67-8795-ec7013811363 csi.storage.k8s.io/serviceAccount.name:default storage.kubernetes.io/csiProvisionerIdentity:1605508257344-8081-hostpath.csi.k8s.io]
mountflags []
I1116 06:54:57.146375 1 mount_linux.go:164] Detected OS without systemd
I1116 06:54:57.146449 1 mount_linux.go:146] Mounting cmd (mount) with arguments ([-o bind /csi-data-dir/9f684dbc-27d8-11eb-884a-0242ac120016 /var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount])
I1116 06:54:57.448129 1 mount_linux.go:146] Mounting cmd (mount) with arguments ([-o bind,remount /csi-data-dir/9f684dbc-27d8-11eb-884a-0242ac120016 /var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount])

先进行create volume，在进行NodePublishVolume

NodeStageVolume的作用

对于块存储来说，设备只能mount到一个目录上，所以NodeStageVolume就是先mount到一个globalmount目录(类似:/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/globalmount)，然后再bind到pod的目录（/var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount/hello-world），这样就可以pv挂载在多个pod中(NodePublishVolume)。在这一步可以进行格式化

参考

如何编写一个CSI插件

Fri, 27 Nov 2020 15:40:59 +0800

这里以csi-driver-host-path作为例子，来看看是如何实现一个csi插件的？

目标：

支持PV动态创建，并且能够挂载在POD中
volume来自本地目录，主要是模拟volume产生的过程，这样就不依赖于某个特定的存储服务

预备知识

在上一篇文章中，已经对CSI概念有个了解，并且提出了CSI组件需要实现的RPC接口，那我们为什么需要这些接口，这需要从volume要被使用经过了以下流程：

volume创建
volume attach到节点(比如像EBS硬盘，NFS可能就直接下一步mount了)
volume 被mount到指定目录(这个目录其实就被映射到容器中，由kubelet 中的VolumeManager 调用)

而当卸载时正好是相反的：unmount,detach,delete volume

正好对应如下图：

 CreateVolume +------------+ DeleteVolume
+------------->| CREATED +--------------+
| +---+----^---+ |
| Controller | | Controller v
+++ Publish | | Unpublish +++
|X| Volume | | Volume | |
+-+ +---v----+---+ +-+
| NODE_READY |
+---+----^---+
Node | | Node
Stage | | Unstage
Volume | | Volume
+---v----+---+
| VOL_READY |
+---+----^---+
Node | | Node
Publish | | Unpublish
Volume | | Volume
+---v----+---+
| PUBLISHED |
+------------+

而为什么多个NodeStageVolume的过程是因为：

对于块存储来说，设备只能mount到一个目录上，所以NodeStageVolume就是先mount到一个globalmount目录(类似:/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/globalmount)，然后再NodePublishVolume这一步中通过mount bind到pod的目录（/var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount/hello-world），这样就可以实现一个pv挂载在多个pod中使用。

代码实现

我们并不一定要实现所有的接口，这个可以通过CSI中Capabilities能力标识出来，我们组件提供的能力，比如

IdentityServer中的GetPluginCapabilities方法
ControllerServer中的ControllerGetCapabilities方法
NodeServer中的NodeGetCapabilities

这些方法都是在告诉调用方，我们的组件实现了哪些能力，未实现的方法就不会调用了。

IdentityServer

IdentityServer包含了三个接口，这里我们主要实现

// IdentityServer is the server API for Identity service.
type IdentityServer interface {
 GetPluginInfo(context.Context, *GetPluginInfoRequest) (*GetPluginInfoResponse, error)
 GetPluginCapabilities(context.Context, *GetPluginCapabilitiesRequest) (*GetPluginCapabilitiesResponse, error)
 Probe(context.Context, *ProbeRequest) (*ProbeResponse, error)
}

主要看下GetPluginCapabilities这个方法：

identityserver.go#L60:

func (ids *identityServer) GetPluginCapabilities(ctx context.Context, req *csi.GetPluginCapabilitiesRequest) (*csi.GetPluginCapabilitiesResponse, error) {
 return &csi.GetPluginCapabilitiesResponse{
 Capabilities: []*csi.PluginCapability{
 {
 Type: &csi.PluginCapability_Service_{
 Service: &csi.PluginCapability_Service{
 Type: csi.PluginCapability_Service_CONTROLLER_SERVICE,
 },
 },
 },
 {
 Type: &csi.PluginCapability_Service_{
 Service: &csi.PluginCapability_Service{
 Type: csi.PluginCapability_Service_VOLUME_ACCESSIBILITY_CONSTRAINTS,
 },
 },
 },
 },
 }, nil
}

以上就告诉调用者我们提供了ControllerService的能力，以及volume访问限制的能力（CSI 处理时需要根据集群拓扑作调整）

PS：其实在k8s还提供了一个包：github.com/kubernetes-csi/drivers/pkg/csi-common，里面提供了比如DefaultIdentityServer，DefaultControllerServer,DefaultNodeServer的struct，只要在我们自己的XXXServer struct中继承这些struct，我们的代码中就只要包含自己实现的方法就行了，可以参考alibaba-cloud-csi-driver中的。

###ControllerServer

ControllerServer我们主要关注CreateVolume,DeleteVolume，因为是hostpath volume，所以就没有attach的这个过程了，我们放在NodeServer中实现：

CreateVolume

controllerserver.go#L73

func (cs *controllerServer) CreateVolume(ctx context.Context, req *csi.CreateVolumeRequest) (*csi.CreateVolumeResponse, error) {
 //校验参数是否有CreateVolume的能力
 if err := cs.validateControllerServiceRequest(csi.ControllerServiceCapability_RPC_CREATE_DELETE_VOLUME); err != nil {
 glog.V(3).Infof("invalid create volume req: %v", req)
 return nil, err
 }

 //.....这里省略的校验参数的过程


 //这里根据volume name判断是否已经存在了，存在了就返回就行了
 if exVol, err := getVolumeByName(req.GetName()); err == nil {
 // volume已经存在，但是大小不符合
 if exVol.VolSize < capacity {
 return nil, status.Errorf(codes.AlreadyExists, "Volume with the same name: %s but with different size already exist", req.GetName())
 }
 //这里判断是否设置了pvc.dataSource，就表示是一个restore过程
 if req.GetVolumeContentSource() != nil {
 volumeSource := req.VolumeContentSource
 switch volumeSource.Type.(type) {
 //校验：从快照中恢复
 case *csi.VolumeContentSource_Snapshot:
 if volumeSource.GetSnapshot() != nil && exVol.ParentSnapID != "" && exVol.ParentSnapID != volumeSource.GetSnapshot().GetSnapshotId() {
 return nil, status.Error(codes.AlreadyExists, "existing volume source snapshot id not matching")
 }
 //校验：clone过程
 case *csi.VolumeContentSource_Volume:
 if volumeSource.GetVolume() != nil && exVol.ParentVolID != volumeSource.GetVolume().GetVolumeId() {
 return nil, status.Error(codes.AlreadyExists, "existing volume source volume id not matching")
 }
 default:
 return nil, status.Errorf(codes.InvalidArgument, "%v not a proper volume source", volumeSource)
 }
 }
 // TODO (sbezverk) Do I need to make sure that volume still exists?
 return &csi.CreateVolumeResponse{
 Volume: &csi.Volume{
 VolumeId: exVol.VolID,
 CapacityBytes: int64(exVol.VolSize),
 VolumeContext: req.GetParameters(),
 ContentSource: req.GetVolumeContentSource(),
 },
 }, nil
 }

 //创建volume
 volumeID := uuid.NewUUID().String()
 //创建hostpath的volume
 vol, err := createHostpathVolume(volumeID, req.GetName(), capacity, requestedAccessType, false /* ephemeral */)
 if err != nil {
 return nil, status.Errorf(codes.Internal, "failed to create volume %v: %v", volumeID, err)
 }
 glog.V(4).Infof("created volume %s at path %s", vol.VolID, vol.VolPath)

 //判断是从快照恢复，还是clone
 if req.GetVolumeContentSource() != nil {
 path := getVolumePath(volumeID)
 volumeSource := req.VolumeContentSource
 switch volumeSource.Type.(type) {
 //从快照恢复
 case *csi.VolumeContentSource_Snapshot:
 if snapshot := volumeSource.GetSnapshot(); snapshot != nil {
 err = loadFromSnapshot(capacity, snapshot.GetSnapshotId(), path, requestedAccessType)
 vol.ParentSnapID = snapshot.GetSnapshotId()
 }
 //clone
 case *csi.VolumeContentSource_Volume:
 if srcVolume := volumeSource.GetVolume(); srcVolume != nil {
 err = loadFromVolume(capacity, srcVolume.GetVolumeId(), path, requestedAccessType)
 vol.ParentVolID = srcVolume.GetVolumeId()
 }
 default:
 err = status.Errorf(codes.InvalidArgument, "%v not a proper volume source", volumeSource)
 }
 if err != nil {
 if delErr := deleteHostpathVolume(volumeID); delErr != nil {
 glog.V(2).Infof("deleting hostpath volume %v failed: %v", volumeID, delErr)
 }
 return nil, err
 }
 glog.V(4).Infof("successfully populated volume %s", vol.VolID)
 }

 //Topology表示volume能够部署在哪些节点（生产情况可能就对应可用区）
 topologies := []*csi.Topology{&csi.Topology{
 Segments: map[string]string{TopologyKeyNode: cs.nodeID},
 }}

 return &csi.CreateVolumeResponse{
 Volume: &csi.Volume{
 VolumeId: volumeID,
 CapacityBytes: req.GetCapacityRange().GetRequiredBytes(),
 VolumeContext: req.GetParameters(),
 ContentSource: req.GetVolumeContentSource(),
 AccessibleTopology: topologies,
 },
 }, nil
}

createHostpathVolume

再来看下createHostpathVolume方法，这里accessType有两个选项，是创建文件系统，还是创建块，其实就是对应pvc中volumeMode字段：

pkg/hostpath/hostpath.go#L208


// createVolume create the directory for the hostpath volume.
// It returns the volume path or err if one occurs.
func createHostpathVolume(volID, name string, cap int64, volAccessType accessType, ephemeral bool) (*hostPathVolume, error) {
 path := getVolumePath(volID)

 switch volAccessType {
 case mountAccess:
 //创建文件
 err := os.MkdirAll(path, 0777)
 if err != nil {
 return nil, err
 }
 case blockAccess:
 //创建块
 executor := utilexec.New()
 size := fmt.Sprintf("%dM", cap/mib)
 // Create a block file.
 _, err := os.Stat(path)
 if err != nil {
 if os.IsNotExist(err) {
 out, err := executor.Command("fallocate", "-l", size, path).CombinedOutput()
 if err != nil {
 return nil, fmt.Errorf("failed to create block device: %v, %v", err, string(out))
 }
 } else {
 return nil, fmt.Errorf("failed to stat block device: %v, %v", path, err)
 }
 }

 // 通过losetup将文件虚拟成块设备
 // Associate block file with the loop device.
 volPathHandler := volumepathhandler.VolumePathHandler{}
 _, err = volPathHandler.AttachFileDevice(path)
 if err != nil {
 // Remove the block file because it'll no longer be used again.
 if err2 := os.Remove(path); err2 != nil {
 glog.Errorf("failed to cleanup block file %s: %v", path, err2)
 }
 return nil, fmt.Errorf("failed to attach device %v: %v", path, err)
 }
 default:
 return nil, fmt.Errorf("unsupported access type %v", volAccessType)
 }

 hostpathVol := hostPathVolume{
 VolID: volID,
 VolName: name,
 VolSize: cap,
 VolPath: path,
 VolAccessType: volAccessType,
 Ephemeral: ephemeral,
 }
 hostPathVolumes[volID] = hostpathVol
 return &hostpathVol, nil
}

DeleteVolume

在DeleteVolume这里主要是删除volume：

pkg/hostpath/controllerserver.go#L2

func (cs *controllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVolumeRequest) (*csi.DeleteVolumeResponse, error) {
 // Check arguments
 if len(req.GetVolumeId()) == 0 {
 return nil, status.Error(codes.InvalidArgument, "Volume ID missing in request")
 }

 if err := cs.validateControllerServiceRequest(csi.ControllerServiceCapability_RPC_CREATE_DELETE_VOLUME); err != nil {
 glog.V(3).Infof("invalid delete volume req: %v", req)
 return nil, err
 }

 volId := req.GetVolumeId()
 if err := deleteHostpathVolume(volId); err != nil {
 return nil, status.Errorf(codes.Internal, "failed to delete volume %v: %v", volId, err)
 }

 glog.V(4).Infof("volume %v successfully deleted", volId)

 return &csi.DeleteVolumeResponse{}, nil
}

在ControllerService中还有一些其他接口，比如CreateSnapshot创建快照，DeleteSnapshot删除快照，扩容等，其实都会依赖于我们存储服务端的提供的能力，调用相应的接口就行了。

NodeServer

在nodeServer中就是实现我们的mount,unmount过程了，分别对应NodePublishVolume和NodeUnpublishVolume

NodePublishVolume

pkg/hostpath/nodeserver.go#L5

func (ns *nodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublishVolumeRequest) (*csi.NodePublishVolumeResponse, error) {
 //......这里省略校验参数代码



 vol, err := getVolumeByID(req.GetVolumeId())
 if err != nil {
 return nil, status.Error(codes.NotFound, err.Error())
 }
 //对应pvc.volumeBind字段是block的情况
 if req.GetVolumeCapability().GetBlock() != nil {
 if vol.VolAccessType != blockAccess {
 return nil, status.Error(codes.InvalidArgument, "cannot publish a non-block volume as block volume")
 }

 volPathHandler := volumepathhandler.VolumePathHandler{}

 //获取device地址（通过loopset -l命令，因为是通过文件虚拟出来的块设备）
 // Get loop device from the volume path.
 loopDevice, err := volPathHandler.GetLoopDevice(vol.VolPath)
 if err != nil {
 return nil, status.Error(codes.Internal, fmt.Sprintf("failed to get the loop device: %v", err))
 }

 mounter := mount.New("")

 // Check if the target path exists. Create if not present.
 _, err = os.Lstat(targetPath)
 if os.IsNotExist(err) {
 if err = mounter.MakeFile(targetPath); err != nil {
 return nil, status.Error(codes.Internal, fmt.Sprintf("failed to create target path: %s: %v", targetPath, err))
 }
 }
 if err != nil {
 return nil, status.Errorf(codes.Internal, "failed to check if the target block file exists: %v", err)
 }

 // Check if the target path is already mounted. Prevent remounting.
 notMount, err := mounter.IsNotMountPoint(targetPath)
 if err != nil {
 if !os.IsNotExist(err) {
 return nil, status.Errorf(codes.Internal, "error checking path %s for mount: %s", targetPath, err)
 }
 notMount = true
 }
 if !notMount {
 // It's already mounted.
 glog.V(5).Infof("Skipping bind-mounting subpath %s: already mounted", targetPath)
 return &csi.NodePublishVolumeResponse{}, nil
 }

 //进行绑定挂载（mount bind），将块设备绑定到容器目录(targetpath类似这种：/var/lib/kubelet/pods/9c5aa371-e5a7-4b67-8795-ec7013811363/volumes/kubernetes.io~csi/pvc-bcfe33ed-e822-4b0e-954a-0f5c0468525e/mount)
 options := []string{"bind"}
 if err := mount.New("").Mount(loopDevice, targetPath, "", options); err != nil {
 return nil, status.Error(codes.Internal, fmt.Sprintf("failed to mount block device: %s at %s: %v", loopDevice, targetPath, err))
 }
 //对应pvc.volumeBind字段是filesystem的情况
 } else if req.GetVolumeCapability().GetMount() != nil {
 //....这里省略，因为跟上面类似也是mount bind过程
 }

 return &csi.NodePublishVolumeResponse{}, nil
}

####NodeUnpublishVolume

NodeUnpublishVolume过程就是unmount过程，如下：

pkg/hostpath/nodeserver.go#L191

func (ns *nodeServer) NodeUnpublishVolume(ctx context.Context, req *csi.NodeUnpublishVolumeRequest) (*csi.NodeUnpublishVolumeResponse, error) {

 // Check arguments
 if len(req.GetVolumeId()) == 0 {
 return nil, status.Error(codes.InvalidArgument, "Volume ID missing in request")
 }
 if len(req.GetTargetPath()) == 0 {
 return nil, status.Error(codes.InvalidArgument, "Target path missing in request")
 }
 targetPath := req.GetTargetPath()
 volumeID := req.GetVolumeId()

 vol, err := getVolumeByID(volumeID)
 if err != nil {
 return nil, status.Error(codes.NotFound, err.Error())
 }

 // Unmount only if the target path is really a mount point.
 if notMnt, err := mount.IsNotMountPoint(mount.New(""), targetPath); err != nil {
 if !os.IsNotExist(err) {
 return nil, status.Error(codes.Internal, err.Error())
 }
 } else if !notMnt {
 // Unmounting the image or filesystem.
 err = mount.New("").Unmount(targetPath)
 if err != nil {
 return nil, status.Error(codes.Internal, err.Error())
 }
 }
 // Delete the mount point.
 // Does not return error for non-existent path, repeated calls OK for idempotency.
 if err = os.RemoveAll(targetPath); err != nil {
 return nil, status.Error(codes.Internal, err.Error())
 }
 glog.V(4).Infof("hostpath: volume %s has been unpublished.", targetPath)

 if vol.Ephemeral {
 glog.V(4).Infof("deleting volume %s", volumeID)
 if err := deleteHostpathVolume(volumeID); err != nil && !os.IsNotExist(err) {
 return nil, status.Error(codes.Internal, fmt.Sprintf("failed to delete volume: %s", err))
 }
 }

 return &csi.NodeUnpublishVolumeResponse{}, nil
}

启动grpc server

pkg/hostpath/hostpath.go#L164

func (hp *hostPath) Run() {
 // Create GRPC servers
 hp.ids = NewIdentityServer(hp.name, hp.version)
 hp.ns = NewNodeServer(hp.nodeID, hp.ephemeral, hp.maxVolumesPerNode)
 hp.cs = NewControllerServer(hp.ephemeral, hp.nodeID)


 s := NewNonBlockingGRPCServer()
 s.Start(hp.endpoint, hp.ids, hp.cs, hp.ns)
 s.Wait()
}

##测试

我们可以通过csc工具来进行grpc接口的测试：

$ GO111MODULE=off go get -u github.com/rexray/gocsi/csc

Get plugin info

$ csc identity plugin-info --endpoint tcp://127.0.0.1:10000
"csi-hostpath" "0.1.0"

Create a volume

$ csc controller new --endpoint tcp://127.0.0.1:10000 --cap 1,block CSIVolumeName
CSIVolumeID

Delete a volume

$ csc controller del --endpoint tcp://127.0.0.1:10000 CSIVolumeID
CSIVolumeID

Validate volume capabilities

$ csc controller validate-volume-capabilities --endpoint tcp://127.0.0.1:10000 --cap 1,block CSIVolumeID
CSIVolumeID true

NodePublish a volume

$ csc node publish --endpoint tcp://127.0.0.1:10000 --cap 1,block --target-path /mnt/hostpath CSIVolumeID
CSIVolumeID

NodeUnpublish a volume

$ csc node unpublish --endpoint tcp://127.0.0.1:10000 --target-path /mnt/hostpath CSIVolumeID
CSIVolumeID

Get Nodeinfo

$ csc node get-info --endpoint tcp://127.0.0.1:10000
CSINode

部署

从上一篇文章中我们可以看到，CSI真正运行起来，其实还需要一些官方提供的组件进行配合，比如node-driver-registrar，csi-provision，csi-attacher，我们将这些container作为我们的sidecar容器，通过volume共享socket连接，方便调用，部署在一起。

我们把服务分为两个部分：

controller ：以Deployment或者Statefulset方式部署，通过leader selector，控制只有一个在工作。
node：以DaemonSet方式部署，在每个节点上都调度

hostpath因为只有在单个节点上测试用，所以它的都使用了Statefulset，因为只是测试。

在生产部署的话可以参考csi-driver-nfs 服务的部署，这个服务比较完整。

当然还有一些rbac，CSIDriver的创建，这里就不贴出来了。

总结

回顾下整个组件是怎么协调工作的：

csi-provisioner组件监听pvc的创建，从而通过 CSI socket 创建 CreateVolumeRequest 请求至CreateVolume方法
csi-provisioner创建 PV 以及更新 PVC状态至 bound ，从而由 controller-manager创建VolumeAttachment对象
csi-attacher 监听VolumeAttachments 对象创建，从而调用 ControllerPublishVolume 方法。
kubelet一直都在等待volume attach，从而调用 NodeStageVolume (主要做格式化以及mount到节点上一个全局目录) 方法 - 这一步可选
CSI Driver在在 NodeStageVolume 方法中将volumemount到 /var/lib/kubelet/plugins/kubernetes.io/csi/pv/<pv-name>/globalmount这个目录并返回给kubelet - 这一步可选
kubelet调用NodePublishVolume (挂载到pod目录通过mount bind)
CSI Driver相应 NodePublishVolume 请求，将volume挂载到pod目录 /var/lib/kubelet/pods/<pod-uuid>/volumes/[kubernetes.io](http://kubernetes.io/)~csi/<pvc-name>/mount
最后，kubelet启动容器

参考

CSI - 容器存储接口

Thu, 26 Nov 2020 15:40:59 +0800

容器存储接口（CSI）是用于将任意块和文件存储系统暴露给诸如Kubernetes之类的容器编排系统（CO）上的容器化工作负载的标准。使用CSI的第三方存储提供商可以编写和部署在Kubernetes中公开新存储系统的插件，而无需接触核心的Kubernetes代码。

具体来说，Kubernetes针对CSI规定了以下内容：

Kubelet到CSI驱动程序的通信
- Kubelet通过Unix域套接字直接向CSI驱动程序发起CSI调用（例如NodeStageVolume，NodePublishVolume等），以挂载和卸载卷。
- Kubelet通过kubelet插件注册机制发现CSI驱动程序（以及用于与CSI驱动程序进行交互的Unix域套接字）。
- 因此，部署在Kubernetes上的所有CSI驱动程序必须在每个受支持的节点上使用kubelet插件注册机制进行注册。
Master到CSI驱动程序的通信
- Kubernetes master组件不会直接（通过Unix域套接字或其他方式）与CSI驱动程序通信。
- Kubernetes master组件仅与Kubernetes API交互。
- 因此，需要依赖于Kubernetes API的操作的CSI驱动程序（例如卷创建，卷attach，卷快照等）必须监听Kubernetes API并针对它触发适当的CSI操作（例如下面的一系列的external组件）。

组件

CSI实现中的组件分为两部分：

由k8s官方维护的一系列external组件负责注册CSI driver 或监听k8s对象资源，从而发起csi driver调用，比如（node-driver-registrar，external-attacher，external-provisioner，external-resizer，external-snapshotter，livenessprobe）
各云厂商or开发者自行开发的组件（需要实现CSI Identity，CSI Controller，CSI Node 接口）

RPC接口(开发商实现)

Identity Service

service Identity {
 //返回driver的信息，比如名字，版本
 rpc GetPluginInfo(GetPluginInfoRequest)
 returns (GetPluginInfoResponse) {}
 //返回driver提供的能力，比如是否提供Controller Service,volume 访问能能力
 rpc GetPluginCapabilities(GetPluginCapabilitiesRequest)
 returns (GetPluginCapabilitiesResponse) {}
 //探针
 rpc Probe (ProbeRequest)
 returns (ProbeResponse) {}
}

Controller service

service Controller {
 //创建卷
 rpc CreateVolume (CreateVolumeRequest)
 returns (CreateVolumeResponse) {}
 //删除卷
 rpc DeleteVolume (DeleteVolumeRequest)
 returns (DeleteVolumeResponse) {}
 //attach 卷
 rpc ControllerPublishVolume (ControllerPublishVolumeRequest)
 returns (ControllerPublishVolumeResponse) {}
 //unattach卷
 rpc ControllerUnpublishVolume (ControllerUnpublishVolumeRequest)
 returns (ControllerUnpublishVolumeResponse) {}
 //返回存储卷的功能点，如是否支持挂载到多个节点上，是否支持多个节点同时读写
 rpc ValidateVolumeCapabilities (ValidateVolumeCapabilitiesRequest)
 returns (ValidateVolumeCapabilitiesResponse) {}
 //列出所有卷
 rpc ListVolumes (ListVolumesRequest)
 returns (ListVolumesResponse) {}
 //返回存储资源池的可用空间大小
 rpc GetCapacity (GetCapacityRequest)
 returns (GetCapacityResponse) {}
 //返回controller插件的功能点，如是否支持GetCapacity接口，是否支持snapshot功能等
 rpc ControllerGetCapabilities (ControllerGetCapabilitiesRequest)
 returns (ControllerGetCapabilitiesResponse) {}
 //创建快照
 rpc CreateSnapshot (CreateSnapshotRequest)
 returns (CreateSnapshotResponse) {}
 //删除快照
 rpc DeleteSnapshot (DeleteSnapshotRequest)
 returns (DeleteSnapshotResponse) {}
 //列出快照
 rpc ListSnapshots (ListSnapshotsRequest)
 returns (ListSnapshotsResponse) {}
 //扩容
 rpc ControllerExpandVolume (ControllerExpandVolumeRequest)
 returns (ControllerExpandVolumeResponse) {}
 //获得卷
 rpc ControllerGetVolume (ControllerGetVolumeRequest)
 returns (ControllerGetVolumeResponse) {
 option (alpha_method) = true;
 }
}

Node Service

service Node {
 //如果存储卷没有格式化，首先要格式化。然后把存储卷mount到一个临时的目录（这个目录通常是节点上的一个全局目录）。再通过NodePublishVolume将存储卷mount到pod的目录中。mount过程分为2步，原因是为了支持多个pod共享同一个volume（如NFS）。
 rpc NodeStageVolume (NodeStageVolumeRequest)
 returns (NodeStageVolumeResponse) {}
 //NodeStageVolume的逆操作，将一个存储卷从临时目录umount掉
 rpc NodeUnstageVolume (NodeUnstageVolumeRequest)
 returns (NodeUnstageVolumeResponse) {}
 //将存储卷从临时目录mount到目标目录（pod目录）
 rpc NodePublishVolume (NodePublishVolumeRequest)
 returns (NodePublishVolumeResponse) {}
 //将存储卷从pod目录umount掉
 rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest)
 returns (NodeUnpublishVolumeResponse) {}
 //返回可用于该卷的卷容量统计信息。
 rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest)
 returns (NodeGetVolumeStatsResponse) {}

 //noe上执行卷扩容
 rpc NodeExpandVolume(NodeExpandVolumeRequest)
 returns (NodeExpandVolumeResponse) {}

 //返回Node插件的功能点，如是否支持stage/unstage功能
 rpc NodeGetCapabilities (NodeGetCapabilitiesRequest)
 returns (NodeGetCapabilitiesResponse) {}
 //返回节点信息
 rpc NodeGetInfo (NodeGetInfoRequest)
 returns (NodeGetInfoResponse) {}
}

###External 组件（k8s Team）

这部分组件是由k8s官方提供的，作为k8s api跟csi driver的桥梁：

node-driver-registrar

CSI node-driver-registrar是一个sidecar容器，可从CSI driver获取驱动程序信息（使用NodeGetInfo），并使用kubelet插件注册机制在该节点上的kubelet中对其进行注册。
external-attacher

它是一个sidecar容器，用于监视Kubernetes VolumeAttachment对象并针对驱动程序端点触发CSI ControllerPublish和ControllerUnpublish操作
external-provisioner

它是一个sidecar容器，用于监视Kubernetes PersistentVolumeClaim对象并针对驱动程序端点触发CSI CreateVolume和DeleteVolume操作。 external-attacher还支持快照数据源。如果将快照CRD资源指定为PVC对象上的数据源，则此sidecar容器通过获取SnapshotContent对象获取有关快照的信息，并填充数据源字段，该字段向存储系统指示应使用指定的快照填充新卷。
external-resizer

它是一个sidecar容器，用于监视Kubernetes API服务器上的PersistentVolumeClaim对象的改动，如果用户请求在PersistentVolumeClaim对象上请求更多存储，则会针对CSI端点触发ControllerExpandVolume操作。
external-snapshotter

它是一个sidecar容器，用于监视Kubernetes API服务器上的VolumeSnapshot和VolumeSnapshotContent CRD对象。创建新的VolumeSnapshot对象（引用与此驱动程序对应的SnapshotClass CRD对象）将导致sidecar容器提供新的快照。该Sidecar侦听指示成功创建VolumeSnapshot的服务，并立即创建VolumeSnapshotContent资源。
livenessprobe

它是一个sidecar容器，用于监视CSI驱动程序的运行状况，并通过Liveness Probe机制将其报告给Kubernetes。这使Kubernetes能够自动检测驱动程序问题并重新启动Pod以尝试解决问题。

参考

源码剖析：KEDA是如何工作的?

Sun, 08 Nov 2020 11:20:59 +0800

文章中源码是基于KEDA 2.0( 50bec80 )来进行分析

keda 2.0 要求k8s集群版本 >=1.16

KEDA 在2020年11月4号release了2.0版本，包含了一些新的比较有用的特性，比如ScaledObject/ScaledJob中支持多触发器、支持HPA原始的CPU、Memory scaler等。

具体的安装使用请参考上一篇文章使用keda完成基于事件的弹性伸缩，这篇文章主要深入的看下KEDA内部机制以及是如何工作的。

我们先提出几个问题，带着问题去看代码，方便我们理解整个机制：

KEDA是如何获取到多种事件的指标，以及如何判断扩缩容的？
KEDA是如何做到将应用的副本数缩容0，依据是什么？

代码结构

对一些主要目录说明，其他一些MD文件主要是文字说明：

├── BRANDING.md
├── BUILD.md //如何在本地编译和运行
├── CHANGELOG.md
├── CONTRIBUTING.md //如何参与贡献次项目
├── CREATE-NEW-SCALER.md
├── Dockerfile
├── Dockerfile.adapter
├── GOVERNANCE.md
├── LICENSE
├── MAINTAINERS.md
├── Makefile // 构建编译相关命令
├── PROJECT
├── README.md
├── RELEASE-PROCESS.MD
├── adapter // keda-metrics-apiserver 组件入口
├── api // 自定义资源定义，例如ScaledObject的定义
├── bin
├── config //组件yaml资源，通过kustomization工具生成
├── controllers //kubebuilder 中controller 代码控制crd资源
├── go.mod
├── go.sum
├── hack
├── images
├── main.go //keda-operator controller入口
├── pkg //包含组件核心代码实现
├── tests //e2e测试
├── tools
├── vendor
└── version

keda中主要是两个组件keda-operator以及keda-metrics-apiserver。

keda-operator ：负责创建/更新HPA以及通过Loop控制应用副本数
keda-metrics-apiserver：实现external-metrics接口，以对接给HPA的external类型的指标查询（比如各种prometheus指标，mysql等）

keda-operator

项目中用到了kubebuilder SDK，用来完成这个Operator的编写。

对于k8s中的自定义controller不了解的可以看看这边文章：如何在Kubernetes中创建一个自定义Controller?。

keda controller的主要流程，画了幅图：

组件启动入口在于main.go文件中：

通过controller-runtime组件启动两个自定义controller：ScaledObjectReconciler,ScaledJobReconciler:

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
 Scheme: scheme,
 MetricsBindAddress: metricsAddr,
 HealthProbeBindAddress: ":8081",
 Port: 9443,
 LeaderElection: enableLeaderElection,
 LeaderElectionID: "operator.keda.sh",
 })
...

// Add readiness probe 
err = mgr.AddReadyzCheck("ready-ping", healthz.Ping)
...
// Add liveness probe
err = mgr.AddHealthzCheck("health-ping", healthz.Ping)
....
//注册 ScaledObject 处理的controller
if err = (&controllers.ScaledObjectReconciler{
 Client: mgr.GetClient(),
 Log: ctrl.Log.WithName("controllers").WithName("ScaledObject"),
 Scheme: mgr.GetScheme(),
}).SetupWithManager(mgr); err != nil {
 setupLog.Error(err, "unable to create controller", "controller", "ScaledObject")
 os.Exit(1)
}
////注册 ScaledJob 处理的controller
if err = (&controllers.ScaledJobReconciler{
 Client: mgr.GetClient(),
 Log: ctrl.Log.WithName("controllers").WithName("ScaledJob"),
 Scheme: mgr.GetScheme(),
}).SetupWithManager(mgr); err != nil {
 setupLog.Error(err, "unable to create controller", "controller", "ScaledJob")
 os.Exit(1)
}

if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
 setupLog.Error(err, "problem running manager")
 os.Exit(1)
}

ScaledObjectReconciler 处理

我们主要关注Reconcile方法，当ScaledObject发生变化时将会触发该方法：方法内部主要功能实现：

...
// 处理删除ScaledObject的情况
if scaledObject.GetDeletionTimestamp() != nil {
 //进入垃圾回收（比如停止goroutine中Loop，恢复原有副本数）
 return ctrl.Result{}, r.finalizeScaledObject(reqLogger, scaledObject)
}

// 给ScaledObject资源加上Finalizer：finalizer.keda.sh
if err := r.ensureFinalizer(reqLogger, scaledObject); err != nil {
 return ctrl.Result{}, err
}
...


// 真正处理ScaledObject资源
msg, err := r.reconcileScaledObject(reqLogger, scaledObject)
// 设置Status字段说明
conditions := scaledObject.Status.Conditions.DeepCopy()
if err != nil {
 reqLogger.Error(err, msg)
 conditions.SetReadyCondition(metav1.ConditionFalse, "ScaledObjectCheckFailed", msg)
 conditions.SetActiveCondition(metav1.ConditionUnknown, "UnkownState", "ScaledObject check failed")
} else {
 reqLogger.V(1).Info(msg)
 conditions.SetReadyCondition(metav1.ConditionTrue, "ScaledObjectReady", msg)
}
kedacontrollerutil.SetStatusConditions(r.Client, reqLogger, scaledObject, &conditions)
return ctrl.Result{}, err

r.reconcileScaledObject方法：

这个方法中主要两个动作：

ensureHPAForScaledObjectExists创建HPA资源
进入requestScaleLoop（不断的检测scaler 是否active，进行副本数的修改）

ensureHPAForScaledObjectExists

通过跟踪进入到newHPAForScaledObject方法:

scaledObjectMetricSpecs, err := r.getScaledObjectMetricSpecs(logger, scaledObject)
...省略代码

hpa := &autoscalingv2beta2.HorizontalPodAutoscaler{
 Spec: autoscalingv2beta2.HorizontalPodAutoscalerSpec{
 MinReplicas: getHPAMinReplicas(scaledObject),
 MaxReplicas: getHPAMaxReplicas(scaledObject),
 Metrics: scaledObjectMetricSpecs,
 Behavior: behavior,
 ScaleTargetRef: autoscalingv2beta2.CrossVersionObjectReference{
 Name: scaledObject.Spec.ScaleTargetRef.Name,
 Kind: gvkr.Kind,
 APIVersion: gvkr.GroupVersion().String(),
 }},
 ObjectMeta: metav1.ObjectMeta{
 Name: getHPAName(scaledObject),
 Namespace: scaledObject.Namespace,
 Labels: labels,
 },
 TypeMeta: metav1.TypeMeta{
 APIVersion: "v2beta2",
 },
}

可以看到创建ScalerObject其实最终也是创建了HPA，其实还是通过HPA本身的特性来控制应用的弹性伸缩。

其中getScaledObjectMetricSpecs方法中就是获取到triggers中的metrics指标。

这里有区分一下External的metrics和resource metrics，因为CPU/Memory scaler是通过resource metrics 来获取的。

requestScaleLoop

requestScaleLoop方法中用来循环check Scaler中的IsActive状态并作出对应的处理，比如修改副本数，直接来看最终的处理吧：这里有两种模型来触发RequestScale：

Pull模型：即主动的调用scaler 中的IsActive方法
Push模型：由Scaler来触发，PushScaler多了一个Run方法，通过channel传入active状态。

IsActive是由Scaler实现的，比如对于prometheus来说，可能指标为0则为false

这个具体的scaler实现后续再讲，我们来看看RequestScale做了什么事：

//当前副本数为0，并是所有scaler属于active状态，则修改副本数为MinReplicaCount 或 1
if currentScale.Spec.Replicas == 0 && isActive {
 e.scaleFromZero(ctx, logger, scaledObject, currentScale)
} else if !isActive &&
 currentScale.Spec.Replicas > 0 &&
 (scaledObject.Spec.MinReplicaCount == nil || *scaledObject.Spec.MinReplicaCount == 0) {
 // 所有scaler都处理not active状态，并且当前副本数大于0，且MinReplicaCount设定为0
 // 则缩容副本数为0
 e.scaleToZero(ctx, logger, scaledObject, currentScale)
} else if !isActive &&
 scaledObject.Spec.MinReplicaCount != nil &&
 currentScale.Spec.Replicas < *scaledObject.Spec.MinReplicaCount {
 // 所有scaler都处理not active状态，并且当前副本数小于MinReplicaCount，则修改为MinReplicaCount
 currentScale.Spec.Replicas = *scaledObject.Spec.MinReplicaCount

 err := e.updateScaleOnScaleTarget(ctx, scaledObject, currentScale)
 ....
} else if isActive {
// 处理active状态，并且副本数大于0，则更新LastActiveTime
 e.updateLastActiveTime(ctx, logger, scaledObject)
} else {
// 不处理
 logger.V(1).Info("ScaleTarget no change")
}

ScaledJobReconciler 处理

ScaledJobReconciler相比ScalerObject少了创建HPA的步骤，其余的步骤主要是通过checkScaledJobScalers，RequestJobScale两个方法来判断Job创建：

checkScaledJobScalers 方法，用于计算isActive，maxValue的值
RequestJobScale 方法，用于负责创建Job，里面还涉及到三种扩容策略

这里直接看代码吧，不贴代码了。

如何停止Loop

这里有个问题就是startPushScalers和startScaleLoop都是在Goroutine中处理的，所以当ScaleObject/ScalerJob被删除的时候，这里需要能够被删除，这里就用到了context.Cancel方法，在Goroutine启动的时候就将，context保存在scaleLoopContexts *sync.Map中(如果已经有了，就先Cancel一次)，在删除资源的时候，进行删除:

func (h *scaleHandler) DeleteScalableObject(scalableObject interface{}) error {
 withTriggers, err := asDuckWithTriggers(scalableObject)
 if err != nil {
 h.logger.Error(err, "error duck typing object into withTrigger")
 return err
 }

 key := generateKey(withTriggers)

 result, ok := h.scaleLoopContexts.Load(key)
 if ok {
 cancel, ok := result.(context.CancelFunc)
 if ok {
 cancel()
 }
 h.scaleLoopContexts.Delete(key)
 } else {
 h.logger.V(1).Info("ScaleObject was not found in controller cache", "key", key)
 }

 return nil
}

ps: 这里的妙啊，学到了

keda-metrics-apiserver

keda-metrics-apiserver实现了ExternalMetricsProvider接口：

type ExternalMetricsProvider interface {
 GetExternalMetric(namespace string, metricSelector labels.Selector, info ExternalMetricInfo) (*external_metrics.ExternalMetricValueList, error)

 ListAllExternalMetrics() []ExternalMetricInfo
}

GetExternalMetric 用于返回Scaler的指标，调用scaler.GetMetrics方法
ListAllExternalMetrics 返回所有支持的external metrics，例如prometheus，mysql等

当代码写好之后，再通过apiservice注册到apiservier上(当然还涉及到鉴权，这里不啰嗦了)：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
labels:
app.kubernetes.io/name: v1beta1.external.metrics.k8s.io
app.kubernetes.io/version: latest
app.kubernetes.io/part-of: keda-operator
name: v1beta1.external.metrics.k8s.io
spec:
service:
name: keda-metrics-apiserver
namespace: keda
group: external.metrics.k8s.io
version: v1beta1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100

实现一个Scaler

其实有两种Scaler，即上面将的一个pull，一个push的模型，PushScaler多了一个Run方法：

实现一个Scaler，主要实现以下接口：

// Scaler interface
type Scaler interface {

 // 返回external_metrics.ExternalMetricValue对象，其实就是用于 keda-metrics-apiserver中获取到scaler的指标
 GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)

 // 返回v2beta2.MetricSpec 结构，主要用于ScalerObject描述创建HPA的类型和Target指标等
 GetMetricSpecForScaling() []v2beta2.MetricSpec
 // 返回该Scaler是否Active，可能会影响Loop中直接修改副本数
 IsActive(ctx context.Context) (bool, error)

 //调用完一次上面的方法就会调用一次Close 
 Close() error
}

// PushScaler interface
type PushScaler interface {
 Scaler

 // 通过scaler实现Run方法，往active channel中，写入值，而非上面的直接调用IsActive放回
 Run(ctx context.Context, active chan<- bool)
}

总结

回过头来我们解答下在开头留下的问题：

KEDA是如何获取到多种事件的指标，以及如何判断扩缩容的？

答：keda controler中生成了external 类型的hpa，并且实现了external metrics 的api
KEDA是如何做到将应用的副本数缩容0，依据是什么？

答： keda 内部有个loop，不断的check isActive状态，会主动的修改应用副本

KEDA - 一个基于事件驱动的伸缩控制器

Wed, 04 Nov 2020 15:40:59 +0800

keda是一个基于事件驱动的伸缩控制器，可以实现应用缩容至0，以及从0开始扩容。目前已支持像CPU/Memroy、Mysql、Prometheus、Redis等20多种事件来源(Scaler)。

目前也是CNCF下的sandbox项目，最初主要由微软、redhat以及社区的人员参与贡献。

网站：https://keda.sh/

项目地址：https://github.com/kedacore/keda

KEDA架构图：

安装

keda 2.0版本要求k8s集群>=1.16

支持多种安装方式，可以查看keda文档：https://keda.sh/docs/2.0/deploy/#install

比如直接使用YAML文件安装：

kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml

检查集群中是否安装成功：

>kubectl get pod -n keda
NAME READY STATUS RESTARTS AGE
keda-metrics-apiserver-5bffbfbd68-s7pbn 1/1 Running 10 2d23h
keda-operator-7b98595dc7-tvgr9 1/1 Running 19 2d23h

基本使用

KEDA 2.0有两种控制对象：

ScaledObject：基于HPA，根据事件触发器(scaler)控制应用(Deployments, StatefulSets & Custom Resources)的水平伸缩
ScaledJob：根据事件触发器(scaler)，生成job

###ScaledObject配置

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: {scaled-object-name}
spec:
 scaleTargetRef:
 apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1
 kind: {kind-of-target-resource} # Optional. Default: Deployment
 name: {name-of-target-resource}  # Mandatory. Must be in the same namespace as the ScaledObject
 envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0]
 pollingInterval: 30 # Optional. Default: 30 seconds
 cooldownPeriod: 300 # Optional. Default: 300 seconds
 minReplicaCount: 0 # Optional. Default: 0
 maxReplicaCount: 100 # Optional. Default: 100
 advanced: # Optional. Section to specify advanced options
 restoreToOriginalReplicaCount: true/false # Optional. Default: false
 horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options
 behavior: # Optional. Use to modify HPA's scaling behavior
 scaleDown:
 stabilizationWindowSeconds: 300
 policies:
 - type: Percent
 value: 100
 periodSeconds: 15
 triggers:
 # {list of triggers to activate scaling of the target resource}

参数说明：

参数	说明
spec.scaleTargetRef	需要扩缩容的对象资源
spec.pollingInterval	定时获取触发器(scaler)的时间间隔，默认30s
spec.cooldownPeriod	上次active至缩容为0需要等待的时间，默认300s
spec.minReplicaCount	应用最小值
spec.maxReplicaCount	应用最大值
spec.advanced.restoreToOriginalReplicaCount	在删除ScaledObject之后，是否将应用恢复为原值
spec.advanced.horizontalPodAutoscalerConfig	HPA对应的配置
spec.triggers	scaler列表

比如创建一个基于prometheus的数据作为触发器的scaledobject:

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
 name: prometheus-scaledobject
 namespace: default
spec:
 scaleTargetRef:
 deploymentName: http-demo
 minReplicaCount: 1
 triggers:
 - type: prometheus
 metadata:
 serverAddress: http://192.168.99.100:31046/
 metricName: gin_requests_total
 threshold: '2'
 query: sum(rate(gin_requests_total{app="http-demo",code="200"}[2m]))

###Scaling Jobs配置

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
 name: {scaled-job-name}
spec:
 jobTargetRef:
 parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#controlling-parallelism)
 completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#controlling-parallelism)
 activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer
 backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6
 template:
 # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 pollingInterval: 30 # Optional. Default: 30 seconds
 successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept.
 failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept.
 envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]
 maxReplicaCount: 100 # Optional. Default: 100
 scalingStrategy:
 strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. 
 customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy.
 customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy.
 triggers:
 # {list of triggers to create jobs}

参数说明：

参数	说明
spec.jobTargetRef	生成的job描述，
spec.pollingInterval	定时获取触发器(scaler)的时间间隔，默认30s
spec.successfulJobsHistoryLimit	保留的success job数量
spec.failedJobsHistoryLimit	保留的failed job数量
spec.envSourceContainerName	通过环境变量设置参数的容器，比如“iam.amazonaws.com/role”参数等
spec.maxReplicaCount	job最大数量
spec.scalingStrategy	job生成策略
spec.triggers	scaler列表

Scaler

支持的Scaler如下：

ActiveMQ Artemis
Apache Kafka
AWS CloudWatch
AWS Kinesis Stream
AWS SQS Queue
Azure Blob Storage
Azure Event Hubs
Azure Log Analytics
Azure Monitor
Azure Service Bus
Azure Storage Queue
CPU
Cron
External
External Push
Google Cloud Platform‎ Pub/Sub
Huawei Cloudeye
IBM MQ
Liiklus Topic
Memory
Metrics API
MySQL
NATS Streaming
PostgreSQL
Prometheus
RabbitMQ Queue
Redis Lists
Redis Streams

源码分析：KEDA是如何工作的?

Wed, 04 Nov 2020 15:40:59 +0800

文章中源码是基于KEDA 2.0( 50bec80)来进行分析

keda 2.0 要求k8s集群版本 >=1.16

KEDA 在2020年11月4号release了2.0版本，包含了一些新的比较有用的特性，比如ScaledObject/ScaledJob中支持多触发器、支持HPA原始的CPU、Memory scaler等。

具体的安装使用请参考上一篇文章使用keda完成基于事件的弹性伸缩，这篇文章主要深入的看下KEDA内部机制以及是如何工作的。

我们先提出几个问题，带着问题去看代码，方便我们理解整个机制：

KEDA是如何获取到多种事件的指标，以及如何判断扩缩容的？
KEDA是如何做到将应用的副本数缩容0，依据是什么？

代码结构

对一些主要目录说明，其他一些MD文件主要是文字说明：

├── BRANDING.md
├── BUILD.md //如何在本地编译和运行
├── CHANGELOG.md
├── CONTRIBUTING.md //如何参与贡献次项目
├── CREATE-NEW-SCALER.md
├── Dockerfile
├── Dockerfile.adapter
├── GOVERNANCE.md
├── LICENSE
├── MAINTAINERS.md
├── Makefile // 构建编译相关命令
├── PROJECT
├── README.md
├── RELEASE-PROCESS.MD
├── adapter // keda-metrics-apiserver 组件入口
├── api // 自定义资源定义，例如ScaledObject的定义
├── bin
├── config //组件yaml资源，通过kustomization工具生成
├── controllers //kubebuilder 中controller 代码控制crd资源
├── go.mod
├── go.sum
├── hack
├── images
├── main.go //keda-operator controller入口
├── pkg //包含组件核心代码实现
├── tests //e2e测试
├── tools
├── vendor
└── version

keda中主要是两个组件keda-operator以及keda-metrics-apiserver。

keda-operator ：负责创建/更新HPA以及通过Loop控制应用副本数
keda-metrics-apiserver：实现external-metrics接口，以对接给HPA的external类型的指标查询（比如各种prometheus指标，mysql等）

keda-operator

项目中用到了kubebuilder SDK，用来完成这个Operator的编写。

对于k8s中的自定义controller不了解的可以看看这边文章：如何在Kubernetes中创建一个自定义Controller?。

keda controller的主要流程，画了幅图：

组件启动入口在于main.go文件中：

通过controller-runtime组件启动两个自定义controller：ScaledObjectReconciler,ScaledJobReconciler:

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
 Scheme: scheme,
 MetricsBindAddress: metricsAddr,
 HealthProbeBindAddress: ":8081",
 Port: 9443,
 LeaderElection: enableLeaderElection,
 LeaderElectionID: "operator.keda.sh",
 })
...

// Add readiness probe 
err = mgr.AddReadyzCheck("ready-ping", healthz.Ping)
...
// Add liveness probe
err = mgr.AddHealthzCheck("health-ping", healthz.Ping)
....
//注册 ScaledObject 处理的controller
if err = (&controllers.ScaledObjectReconciler{
 Client: mgr.GetClient(),
 Log: ctrl.Log.WithName("controllers").WithName("ScaledObject"),
 Scheme: mgr.GetScheme(),
}).SetupWithManager(mgr); err != nil {
 setupLog.Error(err, "unable to create controller", "controller", "ScaledObject")
 os.Exit(1)
}
////注册 ScaledJob 处理的controller
if err = (&controllers.ScaledJobReconciler{
 Client: mgr.GetClient(),
 Log: ctrl.Log.WithName("controllers").WithName("ScaledJob"),
 Scheme: mgr.GetScheme(),
}).SetupWithManager(mgr); err != nil {
 setupLog.Error(err, "unable to create controller", "controller", "ScaledJob")
 os.Exit(1)
}

if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
 setupLog.Error(err, "problem running manager")
 os.Exit(1)
}

ScaledObjectReconciler 处理

我们主要关注Reconcile方法，当ScaledObject发生变化时将会触发该方法：方法内部主要功能实现：

...
// 处理删除ScaledObject的情况
if scaledObject.GetDeletionTimestamp() != nil {
 //进入垃圾回收（比如停止goroutine中Loop，恢复原有副本数）
 return ctrl.Result{}, r.finalizeScaledObject(reqLogger, scaledObject)
}

// 给ScaledObject资源加上Finalizer：finalizer.keda.sh
if err := r.ensureFinalizer(reqLogger, scaledObject); err != nil {
 return ctrl.Result{}, err
}
...


// 真正处理ScaledObject资源
msg, err := r.reconcileScaledObject(reqLogger, scaledObject)
// 设置Status字段说明
conditions := scaledObject.Status.Conditions.DeepCopy()
if err != nil {
 reqLogger.Error(err, msg)
 conditions.SetReadyCondition(metav1.ConditionFalse, "ScaledObjectCheckFailed", msg)
 conditions.SetActiveCondition(metav1.ConditionUnknown, "UnkownState", "ScaledObject check failed")
} else {
 reqLogger.V(1).Info(msg)
 conditions.SetReadyCondition(metav1.ConditionTrue, "ScaledObjectReady", msg)
}
kedacontrollerutil.SetStatusConditions(r.Client, reqLogger, scaledObject, &conditions)
return ctrl.Result{}, err

r.reconcileScaledObject方法：

这个方法中主要两个动作：

ensureHPAForScaledObjectExists创建HPA资源
进入requestScaleLoop（不断的检测scaler 是否active，进行副本数的修改）

ensureHPAForScaledObjectExists

通过跟踪进入到newHPAForScaledObject方法:

scaledObjectMetricSpecs, err := r.getScaledObjectMetricSpecs(logger, scaledObject)
...省略代码

hpa := &autoscalingv2beta2.HorizontalPodAutoscaler{
 Spec: autoscalingv2beta2.HorizontalPodAutoscalerSpec{
 MinReplicas: getHPAMinReplicas(scaledObject),
 MaxReplicas: getHPAMaxReplicas(scaledObject),
 Metrics: scaledObjectMetricSpecs,
 Behavior: behavior,
 ScaleTargetRef: autoscalingv2beta2.CrossVersionObjectReference{
 Name: scaledObject.Spec.ScaleTargetRef.Name,
 Kind: gvkr.Kind,
 APIVersion: gvkr.GroupVersion().String(),
 }},
 ObjectMeta: metav1.ObjectMeta{
 Name: getHPAName(scaledObject),
 Namespace: scaledObject.Namespace,
 Labels: labels,
 },
 TypeMeta: metav1.TypeMeta{
 APIVersion: "v2beta2",
 },
}

可以看到创建ScalerObject其实最终也是创建了HPA，其实还是通过HPA本身的特性来控制应用的弹性伸缩。

其中getScaledObjectMetricSpecs方法中就是获取到triggers中的metrics指标。

这里有区分一下External的metrics和resource metrics，因为CPU/Memory scaler是通过resource metrics 来获取的。

requestScaleLoop

Pull模型：即主动的调用scaler 中的IsActive方法
Push模型：由Scaler来触发，PushScaler多了一个Run方法，通过channel传入active状态。

IsActive是由Scaler实现的，比如对于prometheus来说，可能指标为0则为false

这个具体的scaler实现后续再讲，我们来看看RequestScale做了什么事：

//当前副本数为0，并是所有scaler属于active状态，则修改副本数为MinReplicaCount 或 1
if currentScale.Spec.Replicas == 0 && isActive {
 e.scaleFromZero(ctx, logger, scaledObject, currentScale)
} else if !isActive &&
 currentScale.Spec.Replicas > 0 &&
 (scaledObject.Spec.MinReplicaCount == nil || *scaledObject.Spec.MinReplicaCount == 0) {
 // 所有scaler都处理not active状态，并且当前副本数大于0，且MinReplicaCount设定为0
 // 则缩容副本数为0
 e.scaleToZero(ctx, logger, scaledObject, currentScale)
} else if !isActive &&
 scaledObject.Spec.MinReplicaCount != nil &&
 currentScale.Spec.Replicas < *scaledObject.Spec.MinReplicaCount {
 // 所有scaler都处理not active状态，并且当前副本数小于MinReplicaCount，则修改为MinReplicaCount
 currentScale.Spec.Replicas = *scaledObject.Spec.MinReplicaCount

 err := e.updateScaleOnScaleTarget(ctx, scaledObject, currentScale)
 ....
} else if isActive {
// 处理active状态，并且副本数大于0，则更新LastActiveTime
 e.updateLastActiveTime(ctx, logger, scaledObject)
} else {
// 不处理
 logger.V(1).Info("ScaleTarget no change")
}

ScaledJobReconciler 处理

ScaledJobReconciler相比ScalerObject少了创建HPA的步骤，其余的步骤主要是通过checkScaledJobScalers，RequestJobScale两个方法来判断Job创建：

checkScaledJobScalers 方法，用于计算isActive，maxValue的值
RequestJobScale 方法，用于负责创建Job，里面还涉及到三种扩容策略

这里直接看代码吧，不贴代码了。

如何停止Loop

func (h *scaleHandler) DeleteScalableObject(scalableObject interface{}) error {
 withTriggers, err := asDuckWithTriggers(scalableObject)
 if err != nil {
 h.logger.Error(err, "error duck typing object into withTrigger")
 return err
 }

 key := generateKey(withTriggers)

 result, ok := h.scaleLoopContexts.Load(key)
 if ok {
 cancel, ok := result.(context.CancelFunc)
 if ok {
 cancel()
 }
 h.scaleLoopContexts.Delete(key)
 } else {
 h.logger.V(1).Info("ScaleObject was not found in controller cache", "key", key)
 }

 return nil
}

ps: 这里的妙啊，学到了

keda-metrics-apiserver

keda-metrics-apiserver实现了ExternalMetricsProvider接口：

type ExternalMetricsProvider interface {
 GetExternalMetric(namespace string, metricSelector labels.Selector, info ExternalMetricInfo) (*external_metrics.ExternalMetricValueList, error)

 ListAllExternalMetrics() []ExternalMetricInfo
}

GetExternalMetric 用于返回Scaler的指标，调用scaler.GetMetrics方法
ListAllExternalMetrics 返回所有支持的external metrics，例如prometheus，mysql等

当代码写好之后，再通过apiservice注册到apiservier上(当然还涉及到鉴权，这里不啰嗦了)：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
labels:
app.kubernetes.io/name: v1beta1.external.metrics.k8s.io
app.kubernetes.io/version: latest
app.kubernetes.io/part-of: keda-operator
name: v1beta1.external.metrics.k8s.io
spec:
service:
name: keda-metrics-apiserver
namespace: keda
group: external.metrics.k8s.io
version: v1beta1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100

实现一个Scaler

其实有两种Scaler，即上面将的一个pull，一个push的模型，PushScaler多了一个Run方法：

实现一个Scaler，主要实现以下接口：

// Scaler interface
type Scaler interface {

 // 返回external_metrics.ExternalMetricValue对象，其实就是用于 keda-metrics-apiserver中获取到scaler的指标
 GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)

 // 返回v2beta2.MetricSpec 结构，主要用于ScalerObject描述创建HPA的类型和Target指标等
 GetMetricSpecForScaling() []v2beta2.MetricSpec
 // 返回该Scaler是否Active，可能会影响Loop中直接修改副本数
 IsActive(ctx context.Context) (bool, error)

 //调用完一次上面的方法就会调用一次Close 
 Close() error
}

// PushScaler interface
type PushScaler interface {
 Scaler

 // 通过scaler实现Run方法，往active channel中，写入值，而非上面的直接调用IsActive放回
 Run(ctx context.Context, active chan<- bool)
}

总结

回过头来我们解答下在开头留下的问题：

KEDA是如何获取到多种事件的指标，以及如何判断扩缩容的？

答：keda controler中生成了external 类型的hpa，并且实现了external metrics 的api
KEDA是如何做到将应用的副本数缩容0，依据是什么？

答： keda 内部有个loop，不断的check isActive状态，会主动的修改应用副本

使用keda完成基于事件的弹性伸缩

Mon, 14 Sep 2020 11:20:59 +0800

文章中使用的是keda 1.5版本，2.0还未release 1.5版本支持deployment，job两种资源。而在2.0增加了StatefulSet以及自定义资源

keda 是一个支持多种事件源来对应用进行弹性伸缩的控制器。我觉得keda可以认为是基于HPA的external metrics的一种扩展，因为它利用了hpa中external metrics的能力，允许直接配置多个事件源：

安装keda

从 https://github.com/kedacore/keda/releases 下载1.5版本的zip包，包含了yaml和crd:

├── 00-namespace.yaml
├── 01-service_account.yaml
├── 10-cluster_role.yaml
├── 11-role_binding.yaml
├── 12-operator.yaml
├── 20-metrics-cluster_role.yaml
├── 21-metrics-role_binding.yaml
├── 22-metrics-deployment.yaml
├── 23-metrics-service.yaml
├── 24-metrics-api_service.yaml
└── crds
├── keda.k8s.io_scaledobjects_crd.yaml
└── keda.k8s.io_triggerauthentications_crd.yaml

安装：

kubectl apply -f ./crds/
kubectl apply -f .

以prometheus 和cron两个事件源看下如何使用

配置 ScaledObject

以Deployment为例，看下ScaledObject支持哪些变量

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
name: {scaled-object-name}
spec:
scaleTargetRef:
deploymentName: {deployment-name} # must be in the same namespace as the ScaledObject
containerName: {container-name} #Optional. Default: deployment.spec.template.spec.containers[0]
pollingInterval: 30 # Optional. Default: 30 seconds
cooldownPeriod: 300 # Optional. Default: 300 seconds
minReplicaCount: 0 # Optional. Default: 0
maxReplicaCount: 100 # Optional. Default: 100
triggers:
# {list of triggers to activate the deployment}

基于prometheus指标进行伸缩

我这里有个http demo的应用，上报了gin_requests_total指标到prometheus，通过ab请求http接口模拟压力上升的情况：

这里我将minReplicaCount设置为2，因为在没有流量的时候副本数将会被keda设置为0。

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
name: prometheus-scaledobject
namespace: default
spec:
scaleTargetRef:
deploymentName: http-demo
minReplicaCount: 2
triggers:
- type: prometheus
metadata:
serverAddress: http://192.168.99.100:31046/
metricName: gin_requests_total
threshold: '2'
query: sum(rate(gin_requests_total{app="http-demo",code="200"}[2m]))

当创建该ScaledObject ，我们看到同时创建了一个hpa资源：

➜ example kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
keda-hpa-http-demo Deployment/http-demo 0/2 (avg) 2 100 2 70m

通过压测观察hpa资源变化：

> ab -c 10 -n 1000 http://127.0.0.1:8080/

Every 1.0s: kubectl get hpa anymore.local: Mon Sep 14 14:23:59 2020
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
keda-hpa-http-demo Deployment/http-demo 8/2 (avg) 2 100 4 73m

可以看得到随着流量上升，由hpa控制的副本数在上升，这就达到了我们根据流量扩容的目的，当流量降下来之后，副本数也减少。

组件组成

keda由两个组件组成：

keda operator：负责创建维护hpa对象资源，同时激活和停止hpa伸缩。在无事件的时候将副本数降低为0(如果未设置minReplicaCount的话)
metrics server: 实现了hpa中external metrics，根据事件源配置返回计算结果。

可以看得到HPA控制了副本1->N和N->1的变化。 keda控制了副本0->1和1->0的变化（起到了激活和停止的作用，对于一些消费型的任务副本比较有用，比如在凌晨启动任务进行消费）

扩展事件源(external-scalers)

对于在keda不支持的一些事件源，我们还可以使用keda提供的扩展机制来扩充自己的事件源。 https://keda.sh/docs/1.5/concepts/external-scalers/ 主要是通过grpc实现一下接口实现：

type Scaler interface {
GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)
GetMetricSpecForScaling() []v2beta2.MetricSpec
IsActive(ctx context.Context) (bool, error)
Close() error
}

IsActive 在ScaledObject / ScaledJob CRD中定义的pollingInterval上，每隔pollingInterval时间，调用IsActive，如果返回true，则将比例缩放为1(默认1)
Close调用Close可以使缩放器清除连接或其他资源。
GetMetricSpec 返回缩放器的HPA定义的目标值。
GetMetrics 返回从GetMetricSpec引用的指标的值。

在2.0中还多支持一种PushScaler形式的扩展，允许用户主动push来是否开启/停止基于事件伸缩

总结

之前用过k8s-prometheus-adapter项目来进行应用的自定义指标进行扩展，对比keda感觉keda操作更简单，配置更加动态化，因为抽象了hpa，用户直接操作ScaledObject即可，不需要关注hpa如何进行配置。而且支持将副本数设置为0，同时又拥有类似cronhpa(定时伸缩)的功能，扩展能力比较强。

阅读原文体验更加，文中链接支持跳转

将镜像tar包通过API直接push到registry仓库

Fri, 10 Jul 2020 14:20:59 +0800

为了实现docker tar包能够直接通过页面上传，调研了一下registry的api，以及如何解析tar包（其实就是docker daemon程序实现的部分）。

要想实现，首先要了解docker tar包中结构组成：

tar包结构

拿了一个包含一个镜像的tar包进行解压：

.
├── 1ecf8bc84a7c3d60c0a6bbdd294f12a6b0e17a8269616fc9bdbedd926f74f50c
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── 6f4ec1f3d7ea33646d491a705f94442f5a706e9ac9acbca22fa9b117094eb720.json
├── aaac5bde2c2bcb6cc28b1e6d3f29fe13efce6d6b669300cc2c6bfab96b942af4
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── b63363f0d2ac8b3dca6f903bb5a7301bf497b1e5be8dc4f57a14e4dc649ef9bb
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── c453224a84b8318b0a09a83052314dd876899d3a1a1cf2379e74bba410415059
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── dd8ef1d42fbcccc87927eee94e57519c401b84437b98fcf35505fb6b7267a375
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── manifest.json
└── repositories

文件说明：

manifest.json文件：

[
{
"Config":"6f4ec1f3d7ea33646d491a705f94442f5a706e9ac9acbca22fa9b117094eb720.json",
"RepoTags":[
"alpine:filebeat-6.8.7-arm64"
],
"Layers":[
"aaac5bde2c2bcb6cc28b1e6d3f29fe13efce6d6b669300cc2c6bfab96b942af4/layer.tar",
"dd8ef1d42fbcccc87927eee94e57519c401b84437b98fcf35505fb6b7267a375/layer.tar",
"c453224a84b8318b0a09a83052314dd876899d3a1a1cf2379e74bba410415059/layer.tar",
"b63363f0d2ac8b3dca6f903bb5a7301bf497b1e5be8dc4f57a14e4dc649ef9bb/layer.tar",
"1ecf8bc84a7c3d60c0a6bbdd294f12a6b0e17a8269616fc9bdbedd926f74f50c/layer.tar"
]
}
]

manifest.json 包含了对这个tar包的描述信息，比如image config文件地址，tags说明，镜像layer信息，在解析的时候也是根据这个文件去获取关联的文件。

image config文件

比如：6f4ec1f3d7ea33646d491a705f94442f5a706e9ac9acbca22fa9b117094eb720.json文件：

内容太多就不贴了这里包含了镜像运行的信息，比如env，执行参数，以及镜像历史等。

layer层文件：layer.tar

镜像的每一层的文件信息都打包在了一个单独的layer.tar包中，也是在上传的时候需要用到的。

registry api

流程：

1、获取鉴权信息
2、检查layer.tar是否已经存在
3、上传layer.tar
4、上传image config
5、上传manifest（非包中的manifest.json而是Manifest struct）

这里只列出了在上传的时候需要用的api

1、获取鉴权信息

这里跟registry仓库选择的鉴权方式有关，可选basic auth或者token鉴权。这里我是以最基本的basic auth为例子，如果是token鉴权的方式参考这里： https://docs.docker.com/registry/spec/auth/jwt/

2、检查上传

HEAD /v2/image/blobs/<digest>

若返回200 OK 则表示存在，不用上传

3、开始上传服务我这里是以分块上传的方式进行

POST /v2/image/blobs/uploads/

如果post请求返回202 accepted，一个url会在location字段返回.

 202 Accepted
Location: /v2/\<image>/blobs/uploads/\<uuid>
Range: bytes=0-<offset>
Content-Length: 0
Docker-Upload-UUID: <uuid> # 可以用来查看上传状态和实现断点续传

4、分块上传根据上一步获取的url，以PATCH的方式提交分块数据。如果是最后一块数据上传，则以PUT的方式提交，如下：

 > PUT /v2/<name>/blob/uploads/<uuid>?digest=<digest>
> Content-Length: <size of chunk>
> Content-Range: <start of range>-<end of range>
> Content-Type: application/octet-stream
<Last Layer Chunk Binary Data>

上传layer，image config，manifests信息都是一样的。

我暂时只用到了以上api，更多的api参考：https://docs.docker.com/registry/spec/api/

实现

上面说API没啥感觉，还是看代码比较明白，所以实现了这么一个工具：https://github.com/silenceper/docker-tar-push

Usage:

push your docker tar archive image without docker.
Usage:
docker-tar-push [flags]
Flags:
-h, --help help for docker-tar-push
--log-level int log-level, 0:Fatal,1:Error,2:Warn,3:Info,4:Debug (default 3)
--password string registry auth password
--registry string registry url
--skip-ssl-verify skip ssl verify
--username string registry auth username

Example:

docker-tar-push alpine:latest --registry=http://localhost:5000

参考

在x86_64机器上构建arm64镜像

Fri, 05 Jun 2020 14:20:59 +0800

有几种办法可以打包出arm64的镜像

直接在arm机器上执行编译和打包
通过qemu模拟arm环境
利用docker提供的buildx（需要启用试验性特性）

我没有arm的机器~，所以我主要试了一下下面两种方式。

借助qemu-user-static镜像打包

文档：https://github.com/multiarch/qemu-user-static

开启arm平台支持：

$ docker run --rm --privileged multiarch/qemu-user-static:register --reset

$ docker build --rm -t "test/integration/ubuntu" -<<EOF
FROM multiarch/qemu-user-static:x86_64-aarch64 as qemu
FROM arm64v8/ubuntu
COPY --from=qemu /usr/bin/qemu-aarch64-static /usr/bin
EOF

$ docker run --rm -t "test/integration/ubuntu" uname -m
aarch64

在运行qemu-user-static:register镜像的时候，就通过内核中的binfmt_misc机制注入了哪些可执行文件可以被识别。

注意：需要将qemu-aarch64-static文件 copy 到/usr/bin目录。

binfmt_misc是Linux内核说提供的一种扩展机制, 使得更多类型的文件得以成为＂可执行＂文件．Linux内核本身支持ELF、a.out、脚本（也就是上面所说的第一行#!指定解释器的方式）这集中＂可执行文件＂．但它还提供了一个称为binfmt_misc的内核模块, 通过这个模块可以动态注册一些＂可执行文件格式＂,注册之后我们就可以直接＂执行＂这个程序文件了．

通过buildx打包支持多架构的镜像

文档：https://docs.docker.com/buildx/working-with-buildx/

首先需要开启这个实验性的功能，怎么开启看这里：https://github.com/docker/cli/blob/master/experimental/README.md

docker cloent: 在~/.docker/config.json 加入``写入"experimental":"enabled"
dcoker daemon: 启动参数上加上–experimental或者/etc/docker/daemon.json写入 "experimental": true

进行初始化：

docker buildx create --name builderx
docker buildx use builderx
docker buildx inspect --bootstrap #这一步会从外网拉取`moby/buildkit`镜像，貌似还改不了

接下来你就可以通过如下命令去构建多种架构的镜像：

docker buildx build --platform linux/amd64,linux/arm64 -f Dockerfile -t silenceper/reverse-proxy . --push

--push参数表示构建完成之后，并push到镜像仓库当中。

因为镜像仓库支持一个仓库上传多种架构，并且会根据构建平台pull相匹配架构的镜像，所以我们可以在一个Dockerfile，并且通过一个命令打包镜像并push。

这里用到的Dockerfile在这里：https://github.com/silenceper/reverse-proxy/blob/master/Dockerfile

通过docker的多阶段构建将编译和打包放在一起了，隔离了环境的差异。

FROM golang:alpine as builder
ADD . /go/src/github.com/silenceper/reverse-proxy/
RUN cd /go/src/github.com/silenceper/reverse-proxy/ \
 && go get -v \
 && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine
MAINTAINER silenceper <silenceper@gmail.com>
COPY --from=builder /go/src/github.com/silenceper/reverse-proxy/app /bin/app
ENTRYPOINT ["/bin/app"]
EXPOSE 80

总结

最方便的肯定是直接通过buildx进行打包和编译，但是我的环境没法访问外网，又没法拉取外网的镜像，所以最终还是选择使用qemu-user-static打包出来了。

参考

如何在Kubernetes中创建一个自定义Controller?

Mon, 18 May 2020 18:20:59 +0800

目的

Custom Resource是扩展Kubernetes的一种方式（另外一种就是通过聚合层API apiserver-aggregation），而controller对指定的resource进行监听和执行对应的动作(watch,diff,action)。

Operator与Controller区别

所有的Operator都是用了Controller模式，但并不是所有Controller都是Operator。只有当它满足: controller模式 + API扩展 + 专注于某个App/中间件时，才是一个Operator。
Operator就是使用CRD实现的定制化的Controller. 它与内置K8S Controller遵循同样的运行模式(比如 watch, diff, action)
Operator是特定领域的Controller实现

讨论两者区别：https://github.com/kubeflow/tf-operator/issues/300

所以先学习如何构建出一些自定义的Controller肯定是之后实现Operator的基础。

实现一个自定义的Controller由两部分组成：CRD和Controller逻辑代码
这里以sample-controller的代码为例，同时我们自己写的Controller也可以参考这个代码结构。

CRD资源定义

以sample-controler中的为例，我们需要创建的一个 Foo 如下example-foo.yaml：
创建该 Foo 自定义资源后，期望创建出一个名称为 example-foo ，副本数为 1 的deployment。

apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
 name: example-foo
spec:
 deploymentName: example-foo
 replicas: 1

它的CRD定义如下：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: foos.samplecontroller.k8s.io
spec:
 group: samplecontroller.k8s.io
 version: v1alpha1 #版本
 names:
 kind: Foo # kind类型
 plural: foos # API中使用的名称：/apis/<group>/<version>/<plural>
 scope: Namespaced # Namespaced/Cluster，表示该CRD是命令空间属性还是集群属性
 validation: # 对参数进行验证，应用openAPIV3Schema规则
 openAPIV3Schema:
 properties:
 spec:
 properties:
 # 定义了一个 replicas 字段，类型为integer ，并且在1-10的范围内
 replicas:
 type: integer
 minimum: 1
 maximum: 10

更多关于crd定义规则可以参考官方文档：
https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/

当把这个crd资源apply到集群中后，我们可以通过 kubectl get apiservice v1alpha1.samplecontroller.k8s.io -o yaml 命令看到注册这个 apiservice

代码编写

只需要将我们 Foo resource相关的struct，其余的类似自定义资源的 informers , listers , clientset 以及 deepcopy 的代码都可以通过工具code-generator自动生成。
以及编写我们自定义Controller的业务逻辑代码就好了

struct资源定义

type.go

package v1alpha1

import (
 metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

// +genclient 
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

// Foo is a specification for a Foo resource
type Foo struct {
 metav1.TypeMeta `json:",inline"`
 metav1.ObjectMeta `json:"metadata,omitempty"`

 Spec FooSpec `json:"spec"`
 Status FooStatus `json:"status"`
}

// FooSpec is the spec for a Foo resource
// FooSpec 定义
type FooSpec struct {
 DeploymentName string `json:"deploymentName"`
 Replicas *int32 `json:"replicas"`
}

// FooStatus is the status for a Foo resource
type FooStatus struct {
 AvailableReplicas int32 `json:"availableReplicas"`
}

// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

// FooList is a list of Foo resources
type FooList struct {
 metav1.TypeMeta `json:",inline"`
 metav1.ListMeta `json:"metadata"`

 Items []Foo `json:"items"`
}

其中类似 +k8s: 的注释是代码生成来识别的。

register.go 中将 Foo , FooList 注册进入 scheme 中。

代码生成

代码生成能帮我处理大部分重复代码，主要通过 https://github.com/kubernetes/code-generator 这个包进行解析tag并生成。

全局tag

必须在目标包的doc.go文件中声明，典型路径是 pkg/apis///doc.go。
内容示例：

// 为包中任何类型生成深拷贝方法，可以在局部tag覆盖此默认行为
// +groupName=example.com
// +k8s:deepcopy-gen=package
// +groupName=samplecontroller.k8s.io // groupName指定API组的全限定名

// Package v1alpha1 is the v1alpha1 version of the API.
package v1alpha1 // import "k8s.io/sample-controller/pkg/apis/samplecontroller/v1alpha1"

局部tag

+genclient: 为这个 package 创建 client。
+genclient:noStatus: 当创建 client 时，不存储 status。
+k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object: 为结构体生成 deepcopy 的代码，实现了 runtime.Object 的 Interface。

代码生成：

通过./hack/update-codegen.sh方法可以生成，client以及deepcopy代码。
包含：

sample-controller/pkg/apis/samplecontroller/v1alpha1/zz_generated.deepcopy.go
sample-controller/pkg/generated/clientset
sample-controller/pkg/generated/informers
sample-controller/pkg/generated/informers

_前提：code-generator 已经在vendor中，执行 go mod vendor _

update-codegen.sh内容如下

bash "${CODEGEN_PKG}"/generate-groups.sh "deepcopy,client,informer,lister" \
 k8s.io/sample-controller/pkg/generated k8s.io/sample-controller/pkg/apis \
 samplecontroller:v1alpha1 \
 --output-base "$(dirname "${BASH_SOURCE[0]}")/../../.." \
 --go-header-file "${SCRIPT_ROOT}"/hack/boilerplate.go.txt

完整使用说明：

Usage: generate-groups.sh <generators> <output-package> <apis-package> <groups-versions> ...

 <generators> the generators comma separated to run (deepcopy,defaulter,client,lister,informer) or "all".
 <output-package> the output package name (e.g. github.com/example/project/pkg/generated).
 <apis-package> the external types dir (e.g. github.com/example/api or github.com/example/project/pkg/apis).
 <groups-versions> the groups and their versions in the format "groupA:v1,v2 groupB:v1 groupC:v2", relative
 to <api-package>.
 ... arbitrary flags passed to all generator binaries.


Examples:
 generate-groups.sh all github.com/example/project/pkg/client github.com/example/project/pkg/apis "foo:v1 bar:v1alpha1,v1beta1"
 generate-groups.sh deepcopy,client github.com/example/project/pkg/client github.com/example/project/pkg/apis "foo:v1 bar:v1alpha1,v1beta1"

interface{}处理

场景：如果我们需要一个通用的类型的object，如下：

 validation:
 openAPIV3Schema:
 properties:
 spec:
 properties:
 fields:
 type: object

我们在spec里面定义了一个fields字段，类型是object（即key ,value的形式），value的值可能是int也可能是string或者bool
在type定义的时候我是这么写的，定义为map[string]interface{}

// FooSpec is the spec for a Foo resource
type FooSpec struct {
 Fields map[string]interface{} `json:"fields"`
}

当在代码生成的时候，发现会报错：

Generating deepcopy funcs
F0518 17:53:33.568567 39986 deepcopy.go:750] DeepCopy of "interface{}" is unsupported. Instead, use named interfaces with DeepCopy<named-interface> as one of the methods.
goroutine 1 [running]:
k8s.io/klog/v2.stacks(0xc000132001, 0xc0002e9000, 0xad, 0xfd)
 /Users/silenceper/workspace/golang/pkg/mod/k8s.io/klog/v2@v2.0.0/klog.go:972 +0xb8
 ......

遇到这种问题，需要自己实现深拷贝，例如这种：

type HelmReleaseSpec struct {
 HelmValues `json:",inline"`
}

// +k8s:deepcopy-gen=false
type HelmValues struct {
 helm.Values `json:"values,omitempty"`
}

// helm.Values定义：
type Values map[string]interface{}

// 自己实现深拷贝
func (in *HelmValues) DeepCopyInto(out *HelmValues) {
 if in == nil {
 return
 }

 b, err := yaml.Marshal(in.Values)
 if err != nil {
 return
 }
 var values helm.Values
 err = yaml.Unmarshal(b, &values)
 if err != nil {
 return
 }
 out.Values = values
}

Controller编写

在编写Controller之前需要了解client-go中的informer机制：

黄色的部分是controller相关的框架，包括workqueue。蓝色部分是client-go的相关内容，包括informer, reflector(其实就是informer的封装), indexer。从流程上看，reflector从apiserver中通过list&watch机制接收事件变化，进入Delta FIFO队列中，由informer进行处理。informer会将delta FIFO队列中的事件交给indexer组件，indexer组件会将事件持久化存储在本地的缓存中。之后，由于用户事先将为informer注册各种事件的回调函数，这些回调函数将针对不同的组件做不同的处理。例如在controller中，将把object放入workqueue中，之后由controller的业务逻辑中进行处理。处理的时候将从缓存中获取object的引用。即各组件对资源的处理仅限于本地缓存中，直到update资源的时候才与apiserver交互。

简单来讲通过list/watch机器提供了本地缓存避免每次去请求apiserver。
并且提供了Event Handler方法，在将数据保存进入cache时，通过调用自定义handler方法，增加自定义处理。
所以Controller 的代码结构，就是如下：

func NewController(
 kubeclientset kubernetes.Interface,
 sampleclientset clientset.Interface,
 deploymentInformer appsinformers.DeploymentInformer,
 fooInformer informers.FooInformer) *Controller {
 ....
 fooInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
 AddFunc: controller.enqueueFoo,
 UpdateFunc: func(old, new interface{}) {
 controller.enqueueFoo(new)
 },
 })
 ....
}
func (c *Controller) Run(threadiness int, stopCh <-chan struct{}) error {

 // Launch two workers to process Foo resources
 for i := 0; i < threadiness; i++ {
 go wait.Until(c.runWorker, time.Second, stopCh)
 }
}
func (c *Controller) runWorker() {
 for c.processNextWorkItem() {
 }
}
func (c *Controller) processNextWorkItem() bool {
 obj, shutdown := c.workqueue.Get()
 ...

 err := func(obj interface{}) error {
 ...
 // Run the syncHandler, passing it the namespace/name string of the
 // Foo resource to be synced.
 if err := c.syncHandler(key); err != nil {
 // Put the item back on the workqueue to handle any transient errors.
 c.workqueue.AddRateLimited(key)
 return fmt.Errorf("error syncing '%s': %s, requeuing", key, err.Error())
 }
 ...
 }(obj)
 ...
}
func (c *Controller) syncHandler(key string) error {
 // Convert the namespace/name string into a distinct namespace and name
 namespace, name, err := cache.SplitMetaNamespaceKey(key)
 if err != nil {
 utilruntime.HandleError(fmt.Errorf("invalid resource key: %s", key))
 return nil
 }

 //TODO 处理逻辑
}
func (c *Controller) enqueueFoo(obj interface{}) {
 ...
 c.workqueue.Add(key)
}

在NewController中通过fooInformer添加 AddEventHandler ，执行 enqueueFoo
enqueueFoo 中将获取的变更放入队列
启动一个或多个work从队列中取数据，最终通过syncHandler进行业务判断
在sample-controller中同时还监听了deployment，在 handleObject 判断是否归属 Foo Kind ，同时执行 enqueueFoo 入队。

具体代码判断参考controller.go

在main.go方法中调用如下：


exampleClient, err := clientset.NewForConfig(cfg)
if err != nil {
 klog.Fatalf("Error building example clientset: %s", err.Error())
}
kubeInformerFactory := kubeinformers.NewSharedInformerFactory(kubeClient, time.Second*30)
exampleInformerFactory := informers.NewSharedInformerFactory(exampleClient, time.Second*30)

controller := NewController(kubeClient, exampleClient,
 kubeInformerFactory.Apps().V1().Deployments(),
 exampleInformerFactory.Samplecontroller().V1alpha1().Foos())

// notice that there is no need to run Start methods in a separate goroutine. (i.e. go kubeInformerFactory.Start(stopCh)
// Start method is non-blocking and runs all registered informers in a dedicated goroutine.
kubeInformerFactory.Start(stopCh)
exampleInformerFactory.Start(stopCh) //启动informer

就是调用通过coge-gen生成代码创建informer并启动，创建client。

**思考：为什么要通过队列来控制数据的变化？ **
我觉得用队列一方面是解耦，因为往往一个Controller里面可能要通过informer监听各类资源对象，通过队列借助了各个informer的依赖。另一方便可以通过不同类型的队列比如限速队列，延迟队列达到不同的并发控制。

总结

先定义crd，再实现Controller逻辑
可以通过code-generator生成informer，client，listers代码
注意针对interface{}类型需要自己实现deepCopy方法
实现一个Operator，集成更多更复杂的Controller的话，我们一般使用Operator框架，比如kubebuilder

参考

用vim保存文件和echo命令到底有什么不同？

Wed, 13 May 2020 20:20:59 +0800

现象

最近在调试一个filebeat程序时需要制造一些log，我是直接使用vim直接对文件打开然后直接保存的。

但是有个奇怪的现象：每次写入一行新的日志，filebeat都会将整个文件的内容又重新进行上报一遍导致日志上传重复，同时观察到filebeat的文件采集状态文件registry都会进行增加一个重复的文件(source相同，inode不同)。

操作一番后以为是程序的问题，最后才反应过来（一开始没注意到inode不同 :<），最终使用echo "test some log">>test.log追加的方式发现不会有此问题。

同时看了下两者的inode信息，确认了是因为vim会改变文件的inode(一个新的文件)，echo则不会：

2020-05-14更新：也跟文件权限有关，如果文件没有o没有w权限，则inode信息会改变，如果chmod o+w test.log则inode信息不会变

同时vim也是开了备份文件

1、查看文件inode为908488

[root@localhost work]# stat test.log
 文件："test.log"
 大小：0 块：0 IO 块：4096 普通空文件
设备：fd00h/64768d Inode：908488 硬链接：1
权限：(0644/-rw-r--r--) Uid：( 0/ root) Gid：( 0/ root)
环境：unconfined_u:object_r:admin_home_t:s0
最近访问：2020-05-10 04:38:39.399791808 -0400
最近更改：2020-05-10 04:38:39.399791808 -0400
最近改动：2020-05-10 04:38:39.399791808 -0400
创建时间：-

2、当我用vim/vi工具进行编辑保存之后，变为了：908490

[root@localhost work]# vi test.log
[root@localhost work]# stat test.log
文件："test.log"
大小：7 块：8 IO 块：4096 普通文件
设备：fd00h/64768d Inode：908490 硬链接：1
权限：(0644/-rw-r--r--) Uid：( 0/ root) Gid：( 0/ root)
环境：unconfined_u:object_r:admin_home_t:s0
最近访问：2020-05-10 04:39:01.950055784 -0400
最近更改：2020-05-10 04:39:01.950055784 -0400
最近改动：2020-05-10 04:39:01.953305882 -0400
创建时间：-

3、而用echo命令修改看到inode信息并没有改变, 908490

[root@localhost work]# echo "test some log">>test.log
[root@localhost work]# stat test.log
文件："test.log"
大小：21 块：8 IO 块：4096 普通文件
设备：fd00h/64768d Inode：908490 硬链接：1
权限：(0644/-rw-r--r--) Uid：( 0/ root) Gid：( 0/ root)
环境：unconfined_u:object_r:admin_home_t:s0
最近访问：2020-05-10 04:39:01.950055784 -0400
最近更改：2020-05-10 04:41:16.794459151 -0400
最近改动：2020-05-10 04:41:16.794459151 -0400
创建时间：-

验证

其实通过inode的改变以及可以猜测出在使用vi/vim进行编辑的时候，文件以及变为了一个新的文件，这里我主要通过inotifywait来看一下，在进行vim编辑的时候，文件会产生什么时间

一开始本来打算使用golang中github.com/fsnotify/fsnotify去看的，但是发现包中对event进行了合并，不够原始。所以才直接使用inotifywait 来看

inotifywait命令：

inotifywait -rm test.log

文件权限：

-rw-r--r--. 1 root root 49 5月 14 05:40 test.log

1、使用vim进行编辑的结果：

[root@localhost work]# inotifywait -rm test.log
Setting up watches. Beware: since -r was given, this may take a while!
Watches established.
test.log OPEN
test.log ACCESS
test.log CLOSE_NOWRITE,CLOSE
test.log MOVE_SELF
test.log ATTRIB
test.log DELETE_SELF

可以看到对文件进行了DELETE_SELF

注意当再次进行编辑的时候，已经无法监听到了，因为原有文件已经被删除，需要重新监听

2、使用echo进行追加写入的结果

[root@localhost work]# inotifywait -rm test.log
Setting up watches. Beware: since -r was given, this may take a while!
Watches established.
test.log OPEN
test.log MODIFY
test.log CLOSE_WRITE,CLOSE

3、监听整个目录，可以看到更多信息

[root@localhost work]# inotifywait -rm ./dir/
Setting up watches. Beware: since -r was given, this may take a while!
Watches established.
# 当进行文件写入时
./dir/ OPEN test.log
./dir/ CREATE .test.log.swp
./dir/ OPEN .test.log.swp
./dir/ CREATE .test.log.swx
./dir/ OPEN .test.log.swx
./dir/ CLOSE_WRITE,CLOSE .test.log.swx
./dir/ DELETE .test.log.swx
./dir/ CLOSE_WRITE,CLOSE .test.log.swp
./dir/ DELETE .test.log.swp
./dir/ CREATE .test.log.swp
./dir/ OPEN .test.log.swp
./dir/ MODIFY .test.log.swp
./dir/ ATTRIB .test.log.swp
./dir/ ACCESS test.log
./dir/ CLOSE_NOWRITE,CLOSE test.log
./dir/ MODIFY .test.log.swp
# 当进行文件保存是
./dir/ CREATE 4913
./dir/ OPEN 4913
./dir/ ATTRIB 4913
./dir/ CLOSE_WRITE,CLOSE 4913
./dir/ DELETE 4913
./dir/ MOVED_FROM test.log
./dir/ MOVED_TO test.log~
./dir/ CREATE test.log
./dir/ OPEN test.log
./dir/ MODIFY test.log
./dir/ CLOSE_WRITE,CLOSE test.log
./dir/ ATTRIB test.log
./dir/ MODIFY .test.log.swp
./dir/ DELETE test.log~
./dir/ CLOSE_WRITE,CLOSE .test.log.swp
./dir/ DELETE .test.log.swp

可以看到在进行文件保存时，将原有test.log 移动为test.log~，并新创建一个文件test.log，最后对test.log~备份文件和.test.log.swp缓冲区文件进行删除

4、当进行chmod o+w test.log时，看到的信息如下：

./dir/ CREATE 4913
./dir/ OPEN 4913
./dir/ ATTRIB 4913
./dir/ CLOSE_WRITE,CLOSE 4913
./dir/ DELETE 4913
./dir/ OPEN test.log
./dir/ CREATE test.log~
./dir/ OPEN test.log~
./dir/ ATTRIB test.log~
./dir/ ACCESS test.log
./dir/ MODIFY test.log~
./dir/ CLOSE_WRITE,CLOSE test.log~
./dir/ ATTRIB test.log~
./dir/ CLOSE_NOWRITE,CLOSE test.log
./dir/ MODIFY test.log
./dir/ OPEN test.log
./dir/ MODIFY test.log
./dir/ CLOSE_WRITE,CLOSE test.log
./dir/ ATTRIB test.log
./dir/ MODIFY .test.log.swp
./dir/ DELETE test.log~
./dir/ CLOSE_WRITE,CLOSE .test.log.swp
./dir/ DELETE .test.log.swp

对比3中的结果没有将test.log move to test.log~的操作，而是直接对test.log文件进行更改，所以此时inode信息并没有改变

5、如果关闭vim备份

通过设置vim参数set nobackup nowritebackup关闭vim的备份，则在保存的时候不会生成test.log~文件，这种情况下，inode信息也是不会改变的

总结

vim编辑是产生了一个新的文件，所以看到inode信息变化了，而echo仅仅只是对文件进行写入。
在vim编辑过程中，会生成swp缓冲区文件，在进行vim编辑时时刻将内容保存进入swp，防止程序退出未保存
产生后缀带 ~ 的备份文件，这个是在对文件进行保存时产生，如果文件被正常保存则该文件会被立即删除，正常情况下是看不到这个文件
如果文件other有write权限（chmod o+w xxx），则当进行vi写入内容的时候文件inode不会改变。
如果关闭vim备份，则inode信息也不会改变

postgres入门

Mon, 04 May 2020 23:20:59 +0800

最近需要将mysql数据库切换到pg数据库（公司要求新上的应用DB首选postgres），所以对pg进行基本学习了下，总体感觉相差不大，在一些细节以及需要上可能需要注意。

安装

我这里是以docker的方式来进行安装的。

这种安装方式只能作为作为本地开发调试用

docker run --name postgres -v /Users/silenceper/workspace/postgres/data:/var/lib/postgresql/data -e POSTGRES_PASSWORD=123 -p 5432:5432 -d postgres:10.3

指定数据存储目录映射到宿主机本地，避免容器销毁后数据丢失
指定密码postgres用户的密码为123
指定使用postgres:10.3镜像

可以选择pgAdmin4作为客户端，有图形化UI界面，或者直接使用psql命令。

基本操作

登录数据库（使用psql命令）：

# 进入容器才能使用psql命令
docker exec -it postgres bash
# 以postgres角色登录
psql -U postgres

可以通过 \?查看一些常用的操作。

\h：查看SQL命令的解释，比如\h select。
\?：查看psql命令列表。
\l：列出所有数据库。
\c [database_name]：连接其他数据库。
\d：列出当前数据库的所有表格。
\d [table_name]：列出某一张表格的结构。
\du：列出所有用户。
\e：打开文本编辑器。
\conninfo：列出当前数据库和连接的信息。

创建用户以及DB

创建用户

CREATE USER dbuser WITH PASSWORD 'password';

创建用户数据库，这里为exampledb，并指定所有者为dbuser

CREATE DATABASE exampledb OWNER dbuser;

将exampledb数据库的所有权限都赋予dbuser，否则dbuser只能登录控制台，没有任何数据库操作权限。

GRANT ALL PRIVILEGES ON DATABASE exampledb to dbuser;

最后，使用\q命令退出控制台（也可以直接按ctrl+D）。

\q

数据库操作

# 创建新表
CREATE TABLE user_tbl(name VARCHAR(20), signup_date DATE);
# 插入数据
INSERT INTO user_tbl(name, signup_date) VALUES('张三', '2013-12-22');
# 选择记录
SELECT * FROM user_tbl;
# 更新数据
UPDATE user_tbl set name = '李四' WHERE name = '张三';
# 删除记录
DELETE FROM user_tbl WHERE name = '李四' ;
# 添加栏位
ALTER TABLE user_tbl ADD email VARCHAR(40);
# 更新结构
ALTER TABLE user_tbl ALTER COLUMN signup_date SET NOT NULL;
# 更名栏位
ALTER TABLE user_tbl RENAME COLUMN signup_date TO signup;
# 删除栏位
ALTER TABLE user_tbl DROP COLUMN email;
# 表格更名
ALTER TABLE user_tbl RENAME TO backup_tbl;
# 删除表格
DROP TABLE IF EXISTS backup_tbl;

与mysql对比

原先在mysql中会比较建议用反引号(`)来对字段进行转义，在postgres中就不行了

MySQL 可以使用单引号（’）或者双引号（"）表示值，但是 PG 只能用单引号（’）表示值，PG 的双引号（"）是表示系统标识符的，比如表名或者字段名。MySQL可以使用反单引号（`）表示系统标识符，比如表名、字段名，PG 也是不支持的

时间类型：postgres中时间类型带上with time zone时区

这个在用的时候挺方便的，避免时区不对。

原先一直用https://github.com/silenceper/gogen(一个自动化orm生成工具)来生成db相关的操作一开始只支持mysql，后面加入了postgres的支持就屏蔽了对底层db的选择，方便。

不过对于go开发来说，只要不是手写sql取执行，而是利用一些orm工具，底层都封装了对多种数据库的支持，切换就变得更简单。

这里引入一个话题：golang开发者到底该不该用orm？

我自己觉得，有个取舍，如果需要写的sql比较复杂，关联关系又太多，虽然orm工具也提供了这种关系的对应，但是用的话还不如自己来写sql简单，而且也易读。

如果是业务系统是比较清晰的，已经被拆分的够简单，我基本上都会使用orm工具。

参考文档：https://www.ruanyifeng.com/blog/2013/12/getting_started_with_postgresql.html

记一次问题排查：为什么在POD无法通过Service访问自己？

Thu, 30 Apr 2020 11:26:59 +0800

问题现象

创建一个nginx pod，并配置了service访问，service后端指向pod。

进入pod中使用service ip 或者service 域名，无法访问。

一开始以为是环境配置或者k8s版本（1.9）的问题，在其他1.13的kubernetes环境下也试了，还是同样的问题。

环境配置

使用的cni插件是flannel，但不是容器化安装，也不是标准化的通过kubelet指定cni plugin（–cni-bin-dir,–cni-conf-dir参数），而是通过dockerd 提供的-bip参数指定容器的子网，而这个值是从/run/flannel/subnet.env(flannel会将获取到的子网写入到该文件)

排查过程

1、首先尝试通过pod ip尝试是否可访问，已验证是可通的。

2、尝试对docker0网桥进行抓包

tcpdump -i docker0

神奇的在这里，再次尝试通过service 访问是居然可以通，发现只要tcpdump断开就不行了。

到这里的时候有点觉得诡异了

在pod内通过service访问的时候网络的流向应该是

pod内部访问service->docker0网桥->宿主机的iptables规则->docker0网桥->pod内部

查阅了相关资料后，看到kubelet有个--hairpin-mod参数：

文档说明：

如果网络没有为“发夹模式”流量生成正确配置，通常当 kube-proxy 以 iptables 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。Kubelet 公开了一个 hairpin-mode 标志，如果 pod 试图访问它们自己的 Service VIP，就可以让 Service 的端点重新负载到他们自己身上。hairpin-mode 标志必须设置为 hairpin-veth 或者 promiscuous-bridge。

可是我设置之后还是没有还是不行，翻了一下kubelet里面的代码，发现cni组件并没有取这个值做任何才做（在kubnet中有）

查看这个讨论： https://github.com/kubernetes/kubernetes/issues/45790

大致结论是，应该由cni插件来根据这个值来做对应的操作。

还是没解决我的问题？

不过我看到hairpin开启的标志位是通过/sys/devices/virtual/net/docker0/brif/veth-xxx/hairpin_mod 内容设置为1开启的。

所以我将所有veth该文件内容设置1

for intf in /sys/devices/virtual/net/docker0/brif/*; do echo 1> $intf/hairpin_mod; done

可以访问了。😺

解疑：promiscuous-bridge 与 hairpin-veth

为什么我无法访问

bridge不允许包从收到包的端口发出，比如这种情况，在pod内通过docker0访问service，后续又通过docker0网桥进来，所以需要开启hairpin_mod

为什么使用tcpdump 可以让访问可通？

因为tcpdump要抓取所有经过该网卡，所以需要开启混杂模式。可以在/var/log/message看到device docker0 entered promiscuous mode的log。

混杂模式（英語：promiscuous mode）是电脑网络中的术语。是指一台机器的网卡能够接收所有经过它的数据流，而不论其目的地址是否是它。一般计算机网卡都工作在非混杂模式下，此时网卡只接受来自网络端口的目的地址指向自己的数据。当网卡工作在混杂模式下时，网卡将来自接口的所有数据都捕获并交给相应的驱动程序。

手动开关命令： ifconfig docker0 promisc on/off

总结

其实我们集群通过这种比较另类的方式来分配POD IP也用了了很久了，之所以没出问题，应该是业务基本没遇到这种pod内通过service访问自己的情况。

所以还是要跟着标准的k8s方式来安装cni，避免入坑，比如flannel就已经提供给了hairpinMode 参数来进行配置开启。

singleflight包原理解析

Sun, 08 Mar 2020 19:26:59 +0800

singleflight 包主要是用来做并发控制，常见的比如防止 缓存击穿 ，我们来模拟一下这种场景：

缓存击穿：缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

package main

import (
 "errors"
 "log"
 "sync"

 "golang.org/x/sync/singleflight"
)

var errorNotExist = errors.New("not exist")
func main() {
 var wg sync.WaitGroup
 wg.Add(10)

 //模拟10个并发
 for i := 0; i < 10; i++ {
 go func() {
 defer wg.Done()
 data, err := getData("key")
 if err != nil {
 log.Print(err)
 return
 }
 log.Println(data)
 }()
 }
 wg.Wait()
}

//获取数据
func getData(key string) (string, error) {
 data, err := getDataFromCache(key)
 if err == errorNotExist {
 //模拟从db中获取数据
 data, err = getDataFromDB(key)
 if err != nil {
 log.Println(err)
 return "", err
 }

 //TOOD: set cache
 } else if err != nil {
 return "", err
 }
 return data, nil
}

//模拟从cache中获取值，cache中无该值
func getDataFromCache(key string) (string, error) {
 return "", errorNotExist
}

//模拟从数据库中获取值
func getDataFromDB(key string) (string, error) {
 log.Printf("get %s from database", key)
 return "data", nil
}

其中通过 getData(key)方法获取数据，逻辑是：

先尝试从cache中获取
如果cache中不存在就从db中获取

我们模拟了10个并发请求，来同时调用 getData 函数，执行结果如下：

2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data
2020/03/08 17:13:11 get key from database
2020/03/08 17:13:11 data

可以看得到10个请求都是走的db，因为cache中不存在该值，当我们利用上 singlefligth 包， getData 改动一下：

import "golang.org/x/sync/singleflight"
var g singleflight.Group
//获取数据
func getData(key string) (string, error) {
 data, err := getDataFromCache(key)
 if err == errorNotExist {
 //模拟从db中获取数据
 v, err, _ := g.Do(key, func() (interface{}, error) {
 return getDataFromDB(key)
 //set cache
 })
 if err != nil {
 log.Println(err)
 return "", err
 }

 //TOOD: set cache
 data = v.(string)
 } else if err != nil {
 return "", err
 }
 return data, nil
}

执行结果如下，可以看得到只有一个请求进入的db，其他的请求也正常返回了值，从而保护了后端DB。

2020/03/08 17:18:16 get key from database
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data
2020/03/08 17:18:16 data

原理解析

singleflight 在 golang.org/x/sync/singleflight 项目下，对外提供了以下几个方法

//Do方法，传入key，以及回调函数，如果key相同，fn方法只会执行一次，同步等待
//返回值v:表示fn执行结果
//返回值err:表示fn的返回的err
//第三个返回值shared：表示是否是真实fn返回的还是从保存的map[key]返回的，也就是共享的
func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool) {
//DoChan方法类似Do方法，只是返回的是一个chan
func (g *Group) DoChan(key string, fn func() (interface{}, error)) <-chan Result {
//暂时未用到：设计Forget 控制key关联的值是否失效，默认以上两个方法只要fn方法执行完成后，内部维护的fn的值也删除（即并发结束后就失效了）
func (g *Group) Forget(key string) {

代码也很简单，我们打开上看下，截取了部分： singleflight/singleflight.go

package singleflight // import "golang.org/x/sync/singleflight"

import "sync"

// call is an in-flight or completed singleflight.Do call
type call struct {
 wg sync.WaitGroup

 // These fields are written once before the WaitGroup is done
 // and are only read after the WaitGroup is done.
 //val和err用来记录fn发放执行的返回值
 val interface{}
 err error

 // forgotten indicates whether Forget was called with this call's key
 // while the call was still in flight.
 // 用来标识fn方法执行完成之后结果是否立马删除还是保留在singleflight中
 forgotten bool

 // These fields are read and written with the singleflight
 // mutex held before the WaitGroup is done, and are read but
 // not written after the WaitGroup is done.
 //dups 用来记录fn方法执行的次数
 dups int
 //用来记录DoChan中调用次数以及需要返回的数据
 chans []chan<- Result
}

// Group represents a class of work and forms a namespace in
// which units of work can be executed with duplicate suppression.
type Group struct {
 mu sync.Mutex // protects m
 m map[string]*call // lazily initialized
}


// Do executes and returns the results of the given function, making
// sure that only one execution is in-flight for a given key at a
// time. If a duplicate comes in, the duplicate caller waits for the
// original to complete and receives the same results.
// The return value shared indicates whether v was given to multiple callers.
func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool) {
 g.mu.Lock()
 if g.m == nil {
 g.m = make(map[string]*call)
 }
 //check map是否已经存在值
 if c, ok := g.m[key]; ok {
 c.dups++
 g.mu.Unlock()
 c.wg.Wait()
 return c.val, c.err, true
 }
 c := new(call)
 c.wg.Add(1)
 g.m[key] = c
 g.mu.Unlock()

 g.doCall(c, key, fn)
 return c.val, c.err, c.dups > 0
}
//执行fn方法，并且wg.Done
// doCall handles the single call for a key.
func (g *Group) doCall(c *call, key string, fn func() (interface{}, error)) {
 c.val, c.err = fn()
 c.wg.Done()

 ...
}

在Do方法中主要是通过waitgroup来控制的，主要流程如下：

在Group中设置了一个map，如果key不存在，则实例化call(用来保存值信息)，并将key=>call的对应关系存入map中（通过mutex保证了并发安全）
如果已经在调用中则key已经存在map，则wg.Wait
在fn执行结束之后（在doCall方法中执行）执行wg.Done
卡在第2步的方法得到执行，返回结果

其他的DoChan方法也是类似的逻辑，只是返回的是一个chan。

文中用到的实例代码放在github上： https://github.com/go-demo/singleflight-demo

分析kubernetes中的事件机制

Tue, 03 Mar 2020 12:40:59 +0800

我们通过 kubectl describe [资源] 命令，可以在看到Event输出，并且经常依赖event进行问题定位，从event中可以分析整个POD的运行轨迹，为服务的客观测性提供数据来源，由此可见，event在Kubernetes中起着举足轻重的作用。

event并不只是kubelet中都有的，关于event的操作被封装在client-go/tools/record包，我们完全可以在写入自定义的event。

现在让我们来一步步揭开event的面纱。

Event定义

其实event也是一个资源对象，并且通过apiserver将event存储在etcd中，所以我们也可以通过 kubectl get event 命令查看对应的event对象。

以下是一个event的yaml文件：

apiVersion: v1
count: 1
eventTime: null
firstTimestamp: "2020-03-02T13:08:22Z"
involvedObject:
 apiVersion: v1
 kind: Pod
 name: example-foo-d75d8587c-xsf64
 namespace: default
 resourceVersion: "429837"
 uid: ce611c62-6c1a-4bd8-9029-136a1adf7de4
kind: Event
lastTimestamp: "2020-03-02T13:08:22Z"
message: Pod sandbox changed, it will be killed and re-created.
metadata:
 creationTimestamp: "2020-03-02T13:08:30Z"
 name: example-foo-d75d8587c-xsf64.15f87ea1df862b64
 namespace: default
 resourceVersion: "479466"
 selfLink: /api/v1/namespaces/default/events/example-foo-d75d8587c-xsf64.15f87ea1df862b64
 uid: 9fe6f72a-341d-4c49-960b-e185982d331a
reason: SandboxChanged
reportingComponent: ""
reportingInstance: ""
source:
 component: kubelet
 host: minikube
type: Normal

**
主要字段说明：

involvedObject：触发event的资源类型
lastTimestamp：最后一次触发的时间
message：事件说明
metadata :event的元信息，name，namespace等
reason：event的原因
source：上报事件的来源，比如kubelet中的某个节点
type:事件类型，Normal或Warning

event字段定义可以看这里：types.go#L5078

接下来我们来看看，整个event是如何下入的。

写入事件

1、这里以kubelet为例，看看是如何进行事件写入的

2、文中代码以Kubernetes 1.17.3为例进行分析

先以一幅图来看下整个的处理流程

创建操作事件的客户端：
kubelet/app/server.go#L461

// makeEventRecorder sets up kubeDeps.Recorder if it's nil. It's a no-op otherwise.
func makeEventRecorder(kubeDeps *kubelet.Dependencies, nodeName types.NodeName) {
 if kubeDeps.Recorder != nil {
 return
 }
 //事件广播
 eventBroadcaster := record.NewBroadcaster()
 //创建EventRecorder
 kubeDeps.Recorder = eventBroadcaster.NewRecorder(legacyscheme.Scheme, v1.EventSource{Component: componentKubelet, Host: string(nodeName)})
 //发送event至log输出
 eventBroadcaster.StartLogging(klog.V(3).Infof)
 if kubeDeps.EventClient != nil {
 klog.V(4).Infof("Sending events to api server.")
 //发送event至apiserver
 eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: kubeDeps.EventClient.Events("")})
 } else {
 klog.Warning("No api server defined - no events will be sent to API server.")
 }
}

通过 makeEventRecorder 创建了 EventRecorder 实例，这是一个事件广播器，通过它提供了StartLogging和StartRecordingToSink两个事件处理函数，分别将event发送给log和apiserver。
NewRecorder创建了 EventRecorder 的实例，它提供了 Event ，Eventf 等方法供事件记录。

EventBroadcaster

我们来看下EventBroadcaster接口定义：event.go#L113

// EventBroadcaster knows how to receive events and send them to any EventSink, watcher, or log.
type EventBroadcaster interface {
 //
 StartEventWatcher(eventHandler func(*v1.Event)) watch.Interface
 StartRecordingToSink(sink EventSink) watch.Interface
 StartLogging(logf func(format string, args ...interface{})) watch.Interface
 NewRecorder(scheme *runtime.Scheme, source v1.EventSource) EventRecorder

 Shutdown()
}

具体实现是通过 eventBroadcasterImpl struct来实现了各个方法。

其中StartLogging 和 StartRecordingToSink 其实就是完成了对事件的消费，EventRecorder实现对事件的写入，中间通过channel实现了生产者消费者模型。

`EventRecorder`

我们先来看下EventRecorder 接口定义：event.go#L88，提供了一下4个方法

// EventRecorder knows how to record events on behalf of an EventSource.
type EventRecorder interface {
 // Event constructs an event from the given information and puts it in the queue for sending.
 // 'object' is the object this event is about. Event will make a reference-- or you may also
 // pass a reference to the object directly.
 // 'type' of this event, and can be one of Normal, Warning. New types could be added in future
 // 'reason' is the reason this event is generated. 'reason' should be short and unique; it
 // should be in UpperCamelCase format (starting with a capital letter). "reason" will be used
 // to automate handling of events, so imagine people writing switch statements to handle them.
 // You want to make that easy.
 // 'message' is intended to be human readable.
 //
 // The resulting event will be created in the same namespace as the reference object.
 Event(object runtime.Object, eventtype, reason, message string)

 // Eventf is just like Event, but with Sprintf for the message field.
 Eventf(object runtime.Object, eventtype, reason, messageFmt string, args ...interface{})

 // PastEventf is just like Eventf, but with an option to specify the event's 'timestamp' field.
 PastEventf(object runtime.Object, timestamp metav1.Time, eventtype, reason, messageFmt string, args ...interface{})

 // AnnotatedEventf is just like eventf, but with annotations attached
 AnnotatedEventf(object runtime.Object, annotations map[string]string, eventtype, reason, messageFmt string, args ...interface{})
}

主要参数说明：

object 对应event资源定义中的 involvedObject
eventtype 对应event资源定义中的type，可选Normal，Warning.
reason ：事件原因
message ：事件消息

我们来看下当我们调用 Event(object runtime.Object, eventtype, reason, message string) 的整个过程。
发现最终都调用到了 generateEvent 方法：event.go#L316

func (recorder *recorderImpl) generateEvent(object runtime.Object, annotations map[string]string, timestamp metav1.Time, eventtype, reason, message string) {
 .....
 event := recorder.makeEvent(ref, annotations, eventtype, reason, message)
 event.Source = recorder.source
 go func() {
 // NOTE: events should be a non-blocking operation
 defer utilruntime.HandleCrash()
 recorder.Action(watch.Added, event)
 }()
}

最终事件在一个 goroutine 中通过调用 recorder.Action 进入处理，这里保证了每次调用event方法都是非阻塞的。
其中 makeEvent 的作用主要是构造了一个event对象，事件name根据InvolvedObject中的name加上时间戳生成：

注意看：对于一些非namespace资源产生的event，event的namespace是default

func (recorder *recorderImpl) makeEvent(ref *v1.ObjectReference, annotations map[string]string, eventtype, reason, message string) *v1.Event {
 t := metav1.Time{Time: recorder.clock.Now()}
 namespace := ref.Namespace
 if namespace == "" {
 namespace = metav1.NamespaceDefault
 }
 return &v1.Event{
 ObjectMeta: metav1.ObjectMeta{
 Name: fmt.Sprintf("%v.%x", ref.Name, t.UnixNano()),
 Namespace: namespace,
 Annotations: annotations,
 },
 InvolvedObject: *ref,
 Reason: reason,
 Message: message,
 FirstTimestamp: t,
 LastTimestamp: t,
 Count: 1,
 Type: eventtype,
 }
}

进一步跟踪Action方法，apimachinery/blob/master/pkg/watch/mux.go#L188:23

// Action distributes the given event among all watchers.
func (m *Broadcaster) Action(action EventType, obj runtime.Object) {
 m.incoming <- Event{action, obj}
}

将event写入到了一个channel里面。
注意：
这个Action方式是apimachinery包中的方法，因为实现的sturt recorderImpl
将 *watch.Broadcaster 作为一个匿名struct，并且在 NewRecorder 进行 Broadcaster 赋值，这个Broadcaster其实就是 eventBroadcasterImpl 中的Broadcaster。

到此，基本清楚了event最终被写入到了 Broadcaster 中的 incoming channel中，下面看下是怎么进行消费的。

消费事件

在 makeEventRecorder 调用的 StartLogging 和 StartRecordingToSink 其实就是完成了对事件的消费。

StartLogging直接将event输出到日志
StartRecordingToSink将事件写入到apiserver

两个方法内部都调用了 StartEventWatcher 方法，并且传入一个 eventHandler 方法对event进行处理

func (e *eventBroadcasterImpl) StartEventWatcher(eventHandler func(*v1.Event)) watch.Interface {
 watcher := e.Watch()
 go func() {
 defer utilruntime.HandleCrash()
 for watchEvent := range watcher.ResultChan() {
 event, ok := watchEvent.Object.(*v1.Event)
 if !ok {
 // This is all local, so there's no reason this should
 // ever happen.
 continue
 }
 eventHandler(event)
 }
 }()
 return watcher
}

其中 watcher.ResultChan 方法就拿到了事件，这里是在一个goroutine中通过func (m *Broadcaster) loop() ==>func (m *Broadcaster) distribute(event Event) 方法调用将event又写入了broadcasterWatcher.result

主要看下 StartRecordingToSink 提供的的eventHandler， recordToSink 方法：

func recordToSink(sink EventSink, event *v1.Event, eventCorrelator *EventCorrelator, sleepDuration time.Duration) {
 // Make a copy before modification, because there could be multiple listeners.
 // Events are safe to copy like this.
 eventCopy := *event
 event = &eventCopy
 result, err := eventCorrelator.EventCorrelate(event)
 if err != nil {
 utilruntime.HandleError(err)
 }
 if result.Skip {
 return
 }
 tries := 0
 for {
 if recordEvent(sink, result.Event, result.Patch, result.Event.Count > 1, eventCorrelator) {
 break
 }
 tries++
 if tries >= maxTriesPerEvent {
 klog.Errorf("Unable to write event '%#v' (retry limit exceeded!)", event)
 break
 }
 // Randomize the first sleep so that various clients won't all be
 // synced up if the master goes down.
 // 第一次重试增加随机性，防止 apiserver 重启的时候所有的事件都在同一时间发送事件
 if tries == 1 {
 time.Sleep(time.Duration(float64(sleepDuration) * rand.Float64()))
 } else {
 time.Sleep(sleepDuration)
 }
 }
}

其中event被经过了一个 eventCorrelator.EventCorrelate(event) 方法做预处理，主要是聚合相同的事件（避免产生的事件过多，增加 etcd 和 apiserver 的压力，也会导致查看 pod 事件很不清晰）

下面一个for循环就是在进行重试，最大重试次数是12次，调用 recordEvent 方法才真正将event写入到了apiserver。

事件处理

我们来看下EventCorrelate方法：

// EventCorrelate filters, aggregates, counts, and de-duplicates all incoming events
func (c *EventCorrelator) EventCorrelate(newEvent *v1.Event) (*EventCorrelateResult, error) {
 if newEvent == nil {
 return nil, fmt.Errorf("event is nil")
 }
 aggregateEvent, ckey := c.aggregator.EventAggregate(newEvent)
 observedEvent, patch, err := c.logger.eventObserve(aggregateEvent, ckey)
 if c.filterFunc(observedEvent) {
 return &EventCorrelateResult{Skip: true}, nil
 }
 return &EventCorrelateResult{Event: observedEvent, Patch: patch}, err
}

分别调用了 aggregator.EventAggregate ， logger.eventObserve ， filterFunc 三个方法，分别作用是：

aggregator.EventAggregate：聚合event，如果在最近 10 分钟出现过 10 个相似的事件（除了 message 和时间戳之外其他关键字段都相同的事件），aggregator 会把它们的 message 设置为 (combined from similar events)+event.Message
logger.eventObserve：它会把相同的事件以及包含 aggregator 被聚合了的相似的事件，通过增加 Count 字段来记录事件发生了多少次。
filterFunc: 这里实现了一个基于令牌桶的限流算法，如果超过设定的速率则丢弃，保证了apiserver的安全。

我们主要来看下aggregator.EventAggregate方法：

func (e *EventAggregator) EventAggregate(newEvent *v1.Event) (*v1.Event, string) {
 now := metav1.NewTime(e.clock.Now())
 var record aggregateRecord
 // eventKey is the full cache key for this event
 //eventKey 是将除了时间戳外所有字段结合在一起
 eventKey := getEventKey(newEvent)
 // aggregateKey is for the aggregate event, if one is needed.
 //aggregateKey 是除了message和时间戳外的字段结合在一起，localKey 是message
 aggregateKey, localKey := e.keyFunc(newEvent)

 // Do we have a record of similar events in our cache?
 e.Lock()
 defer e.Unlock()
 //从cache中根据aggregateKey查询是否存在，如果是相同或者相类似的事件会被放入cache中
 value, found := e.cache.Get(aggregateKey)
 if found {
 record = value.(aggregateRecord)
 }

 //判断上次事件产生的时间是否超过10分钟，如何操作则重新生成一个localKeys集合（集合中存放message）
 maxInterval := time.Duration(e.maxIntervalInSeconds) * time.Second
 interval := now.Time.Sub(record.lastTimestamp.Time)
 if interval > maxInterval {
 record = aggregateRecord{localKeys: sets.NewString()}
 }

 // Write the new event into the aggregation record and put it on the cache
 //将locakKey也就是message放入集合中，如果message相同就是覆盖了
 record.localKeys.Insert(localKey)
 record.lastTimestamp = now
 e.cache.Add(aggregateKey, record)

 // If we are not yet over the threshold for unique events, don't correlate them
 //判断localKeys集合中存放的类似事件是否超过10个，
 if uint(record.localKeys.Len()) < e.maxEvents {
 return newEvent, eventKey
 }

 // do not grow our local key set any larger than max
 record.localKeys.PopAny()

 // create a new aggregate event, and return the aggregateKey as the cache key
 // (so that it can be overwritten.)
 eventCopy := &v1.Event{
 ObjectMeta: metav1.ObjectMeta{
 Name: fmt.Sprintf("%v.%x", newEvent.InvolvedObject.Name, now.UnixNano()),
 Namespace: newEvent.Namespace,
 },
 Count: 1,
 FirstTimestamp: now,
 InvolvedObject: newEvent.InvolvedObject,
 LastTimestamp: now,
 //这里会对message加个前缀：(combined from similar events):
 Message: e.messageFunc(newEvent),
 Type: newEvent.Type,
 Reason: newEvent.Reason,
 Source: newEvent.Source,
 }
 return eventCopy, aggregateKey
}

aggregator.EventAggregate方法中其实就是判断了通过cache和localKeys判断事件是否相似，如果最近 10 分钟出现过 10 个相似的事件就合并并加上前缀，后续通过logger.eventObserve方法进行count累加，如果message也相同，肯定就是直接count++。

总结

好了，event处理的整个流程基本就是这样，我们可以概括一下，可以结合文中的图对比一起看下：

创建 EventRecorder 对象，通过其提供的 Event 等方法，创建好event对象
将创建出来的对象发送给 EventBroadcaster 中的channel中
EventBroadcaster 通过后台运行的goroutine，从管道中取出事件，并广播给提前注册好的handler处理
当输出log的handler收到事件就直接打印事件
当 EventSink handler收到处理事件就通过预处理之后将事件发送给apiserver
其中预处理包含三个动作，1、限流 2、聚合 3、计数
apiserver收到事件处理之后就存储在etcd中

回顾event的整个流程，可以看到event并不是保证100%事件写入（从预处理的过程来看），这样做是为了后端服务etcd的可用性，因为event事件在整个集群中产生是非常频繁的，尤其在服务不稳定的时候，而相比Deployment,Pod等其他资源，又没那么的重要。所以这里做了个取舍。

参考文档：

https://cizixs.com/2017/06/22/kubelet-source-code-analysis-part4-event/

利用Kubernetes中的leaderelection实现组件高可用

Sat, 15 Feb 2020 00:00:00 +0000

在Kubernetes中，通常kube-schduler和kube-controller-manager都是多副本进行部署的来保证高可用，而真正在工作的实例其实只有一个。这里就利用到 leaderelection 的选主机制，保证leader是处于工作状态，并且在leader挂掉之后，从其他节点选取新的leader保证组件正常工作。

不单单只是k8s中的这两个组件用到，在其他服务中也可以看到这个包的使用，比如cluster-autoscaler等都能看得到这个包的，今天就来看看这个包的使用以及它内部是如何实现的。

使用

以下是一个简单使用的例子，编译完成之后同时启动多个进程，但是只有一个进程在工作，当把leader进程kill掉之后，会重新选举出一个leader进行工作，即执行其中的 run 方法：

/*
例子来源于client-go中的example包中
*/

package main

import (
 "context"
 "flag"
 "os"
 "os/signal"
 "syscall"
 "time"

 "github.com/google/uuid"
 metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 clientset "k8s.io/client-go/kubernetes"
 "k8s.io/client-go/rest"
 "k8s.io/client-go/tools/clientcmd"
 "k8s.io/client-go/tools/leaderelection"
 "k8s.io/client-go/tools/leaderelection/resourcelock"
 "k8s.io/klog"
)

func buildConfig(kubeconfig string) (*rest.Config, error) {
 if kubeconfig != "" {
 cfg, err := clientcmd.BuildConfigFromFlags("", kubeconfig)
 if err != nil {
 return nil, err
 }
 return cfg, nil
 }

 cfg, err := rest.InClusterConfig()
 if err != nil {
 return nil, err
 }
 return cfg, nil
}

func main() {
 klog.InitFlags(nil)

 var kubeconfig string
 var leaseLockName string
 var leaseLockNamespace string
 var id string

 flag.StringVar(&kubeconfig, "kubeconfig", "", "absolute path to the kubeconfig file")
 flag.StringVar(&id, "id", uuid.New().String(), "the holder identity name")
 flag.StringVar(&leaseLockName, "lease-lock-name", "", "the lease lock resource name")
 flag.StringVar(&leaseLockNamespace, "lease-lock-namespace", "", "the lease lock resource namespace")
 flag.Parse()

 if leaseLockName == "" {
 klog.Fatal("unable to get lease lock resource name (missing lease-lock-name flag).")
 }
 if leaseLockNamespace == "" {
 klog.Fatal("unable to get lease lock resource namespace (missing lease-lock-namespace flag).")
 }

 // leader election uses the Kubernetes API by writing to a
 // lock object, which can be a LeaseLock object (preferred),
 // a ConfigMap, or an Endpoints (deprecated) object.
 // Conflicting writes are detected and each client handles those actions
 // independently.
 config, err := buildConfig(kubeconfig)
 if err != nil {
 klog.Fatal(err)
 }
 client := clientset.NewForConfigOrDie(config)

 run := func(ctx context.Context) {
 // complete your controller loop here
 klog.Info("Controller loop...")

 select {}
 }

 // use a Go context so we can tell the leaderelection code when we
 // want to step down
 ctx, cancel := context.WithCancel(context.Background())
 defer cancel()

 // listen for interrupts or the Linux SIGTERM signal and cancel
 // our context, which the leader election code will observe and
 // step down
 ch := make(chan os.Signal, 1)
 signal.Notify(ch, os.Interrupt, syscall.SIGTERM)
 go func() {
 <-ch
 klog.Info("Received termination, signaling shutdown")
 cancel()
 }()

 // we use the Lease lock type since edits to Leases are less common
 // and fewer objects in the cluster watch "all Leases".
 // 指定锁的资源对象，这里使用了Lease资源，还支持configmap，endpoint，或者multilock(即多种配合使用)
 lock := &resourcelock.LeaseLock{
 LeaseMeta: metav1.ObjectMeta{
 Name: leaseLockName,
 Namespace: leaseLockNamespace,
 },
 Client: client.CoordinationV1(),
 LockConfig: resourcelock.ResourceLockConfig{
 Identity: id,
 },
 }

 // start the leader election code loop
 leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{
 Lock: lock,
 // IMPORTANT: you MUST ensure that any code you have that
 // is protected by the lease must terminate **before**
 // you call cancel. Otherwise, you could have a background
 // loop still running and another process could
 // get elected before your background loop finished, violating
 // the stated goal of the lease.
 ReleaseOnCancel: true,
 LeaseDuration: 60 * time.Second,//租约时间
 RenewDeadline: 15 * time.Second,//更新租约的
 RetryPeriod: 5 * time.Second,//非leader节点重试时间
 Callbacks: leaderelection.LeaderCallbacks{
 OnStartedLeading: func(ctx context.Context) {
 //变为leader执行的业务代码
 // we're notified when we start - this is where you would
 // usually put your code
 run(ctx)
 },
 OnStoppedLeading: func() {
 // 进程退出
 // we can do cleanup here
 klog.Infof("leader lost: %s", id)
 os.Exit(0)
 },
 OnNewLeader: func(identity string) {
 //当产生新的leader后执行的方法
 // we're notified when new leader elected
 if identity == id {
 // I just got the lock
 return
 }
 klog.Infof("new leader elected: %s", identity)
 },
 },
 })
}

关键启动参数说明：

kubeconfig: 指定kubeconfig文件地址
lease-lock-name：指定lock的名称
lease-lock-namespace：指定lock存储的namespace
id: 例子中提供的区别参数，用于区分实例
logtostderr：klog提供的参数，指定log输出到控制台
v: 指定日志输出级别

同时启动两个进程：
启动进程1：

go run main.go -kubeconfig=/Users/silenceper/.kube/config -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=1 -v=4
I0215 19:56:37.049658 48045 leaderelection.go:242] attempting to acquire leader lease default/example...
I0215 19:56:37.080368 48045 leaderelection.go:252] successfully acquired lease default/example
I0215 19:56:37.080437 48045 main.go:87] Controller loop...

启动进程2：

➜ leaderelection git:(master) ✗ go run main.go -kubeconfig=/Users/silenceper/.kube/config -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=2 -v=4
I0215 19:57:35.870051 48791 leaderelection.go:242] attempting to acquire leader lease default/example...
I0215 19:57:35.894735 48791 leaderelection.go:352] lock is held by 1 and has not yet expired
I0215 19:57:35.894769 48791 leaderelection.go:247] failed to acquire lease default/example
I0215 19:57:35.894790 48791 main.go:151] new leader elected: 1
I0215 19:57:44.532991 48791 leaderelection.go:352] lock is held by 1 and has not yet expired
I0215 19:57:44.533028 48791 leaderelection.go:247] failed to acquire lease default/example

这里可以看出来id=1的进程持有锁，并且运行的程序，而id=2的进程表示无法获取到锁，在不断的进程尝试。

现在kill掉id=1进程，在等待lock释放之后（有个LeaseDuration时间），leader变为id=2的进程执行工作

I0215 20:01:41.489300 48791 leaderelection.go:252] successfully acquired lease default/example
I0215 20:01:41.489577 48791 main.go:87] Controller loop...

深入理解

基本原理其实就是利用通过Kubernetes中 configmap ， endpoints 或者 lease 资源实现一个分布式锁，抢(acqure)到锁的节点成为leader，并且定期更新（renew）。其他进程也在不断的尝试进行抢占，抢占不到则继续等待下次循环。当leader节点挂掉之后，租约到期，其他节点就成为新的leader。

入口

通过 leaderelection.RunOrDie 启动，

func RunOrDie(ctx context.Context, lec LeaderElectionConfig) {
 le, err := NewLeaderElector(lec)
 if err != nil {
 panic(err)
 }
 if lec.WatchDog != nil {
 lec.WatchDog.SetLeaderElection(le)
 }
 le.Run(ctx)
}

传入参数 LeaderElectionConfig ：

type LeaderElectionConfig struct {
 // Lock 的类型
 Lock rl.Interface
 //持有锁的时间
 LeaseDuration time.Duration
 //在更新租约的超时时间
 RenewDeadline time.Duration
 //竞争获取锁的时间
 RetryPeriod time.Duration
 //状态变化时执行的函数，支持三种：
 //1、OnStartedLeading 启动是执行的业务代码
 //2、OnStoppedLeading leader停止执行的方法
 //3、OnNewLeader 当产生新的leader后执行的方法
 Callbacks LeaderCallbacks

 //进行监控检查
 // WatchDog is the associated health checker
 // WatchDog may be null if its not needed/configured.
 WatchDog *HealthzAdaptor
 //leader退出时，是否执行release方法
 ReleaseOnCancel bool

 // Name is the name of the resource lock for debugging
 Name string
}

LeaderElectionConfig.lock 支持保存在以下三种资源中：
configmap
endpoint
lease
包中还提供了一个 multilock ，即可以进行选择两种，当其中一种保存失败时，选择第二张
可以在interface.go中看到：

 switch lockType {
 case EndpointsResourceLock://保存在endpoints
 return endpointsLock, nil
 case ConfigMapsResourceLock://保存在configmaps
 return configmapLock, nil
 case LeasesResourceLock://保存在leases
 return leaseLock, nil
 case EndpointsLeasesResourceLock://优先尝试保存在endpoint失败时保存在lease
 return &MultiLock{
 Primary: endpointsLock,
 Secondary: leaseLock,
 }, nil
 case ConfigMapsLeasesResourceLock://优先尝试保存在configmap，失败时保存在lease
 return &MultiLock{
 Primary: configmapLock,
 Secondary: leaseLock,
 }, nil
 default:
 return nil, fmt.Errorf("Invalid lock-type %s", lockType)
 }

以lease资源对象为例，可以在查看到保存的内容:

➜ ~ kubectl get lease example -n default -o yaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
 creationTimestamp: "2020-02-15T11:56:37Z"
 name: example
 namespace: default
 resourceVersion: "210675"
 selfLink: /apis/coordination.k8s.io/v1/namespaces/default/leases/example
 uid: a3470a06-6fc3-42dc-8242-9d6cebdf5315
spec:
 acquireTime: "2020-02-15T12:01:41.476971Z"//获得锁时间
 holderIdentity: "2"//持有锁进程的标识
 leaseDurationSeconds: 60//lease租约
 leaseTransitions: 1//leader更换次数
 renewTime: "2020-02-15T12:05:37.134655Z"//更新租约的时间

关注其spec中的字段，分别进行标注,对应结构体如下：

type LeaderElectionRecord struct {
 HolderIdentity string `json:"holderIdentity"`//持有锁进程的标识，一般可以利用主机名
 LeaseDurationSeconds int `json:"leaseDurationSeconds"`// lock的租约
 AcquireTime metav1.Time `json:"acquireTime"`//持有锁的时间
 RenewTime metav1.Time `json:"renewTime"`//更新时间
 LeaderTransitions int `json:"leaderTransitions"`//leader更换的次数
}

获取的锁以及更新锁

Run方法中包含了获取锁以及更新锁的入口

// Run starts the leader election loop
func (le *LeaderElector) Run(ctx context.Context) {
 defer func() {
 //进行退出执行
 runtime.HandleCrash()
 //停止时执行回调方法
 le.config.Callbacks.OnStoppedLeading()
 }()
 //不断的进行获得锁，如果获得锁成功则执行后面的方法，否则不断的进行重试
 if !le.acquire(ctx) {
 return // ctx signalled done
 }
 ctx, cancel := context.WithCancel(ctx)
 defer cancel()
 //获取锁成功，当前进程变为leader，执行回调函数中的业务代码
 go le.config.Callbacks.OnStartedLeading(ctx)
 //不断的循环进行进行租约的更新，保证锁一直被当前进行持有
 le.renew(ctx)
}

le.acquire 和 le.renew 内部都是调用了 le.tryAcquireOrRenew 函数，只是对于返回结果的处理不一样。

le.acquire 对于 le.tryAcquireOrRenew 返回成功则退出，失败则继续。

le.renew 则相反，成功则继续，失败则退出。

我们来看看 tryAcquireOrRenew 方法：

func (le *LeaderElector) tryAcquireOrRenew() bool {
 now := metav1.Now()
 //锁资源对象内容
 leaderElectionRecord := rl.LeaderElectionRecord{
 HolderIdentity: le.config.Lock.Identity(),//唯一标识
 LeaseDurationSeconds: int(le.config.LeaseDuration / time.Second),
 RenewTime: now,
 AcquireTime: now,
 }

 // 1. obtain or create the ElectionRecord
 // 第一步：从k8s资源中获取原有的锁
 oldLeaderElectionRecord, oldLeaderElectionRawRecord, err := le.config.Lock.Get()
 if err != nil {
 if !errors.IsNotFound(err) {
 klog.Errorf("error retrieving resource lock %v: %v", le.config.Lock.Describe(), err)
 return false
 }
 //资源对象不存在，进行锁资源创建
 if err = le.config.Lock.Create(leaderElectionRecord); err != nil {
 klog.Errorf("error initially creating leader election record: %v", err)
 return false
 }
 le.observedRecord = leaderElectionRecord
 le.observedTime = le.clock.Now()
 return true
 }

 // 2. Record obtained, check the Identity & Time
 // 第二步，对比存储在k8s中的锁资源与上一次获取的锁资源是否一致
 if !bytes.Equal(le.observedRawRecord, oldLeaderElectionRawRecord) {
 le.observedRecord = *oldLeaderElectionRecord
 le.observedRawRecord = oldLeaderElectionRawRecord
 le.observedTime = le.clock.Now()
 }
 //判断持有的锁是否到期以及是否被自己持有
 if len(oldLeaderElectionRecord.HolderIdentity) > 0 &&
 le.observedTime.Add(le.config.LeaseDuration).After(now.Time) &&
 !le.IsLeader() {
 klog.V(4).Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity)
 return false
 }

 // 3. We're going to try to update. The leaderElectionRecord is set to it's default
 // here. Let's correct it before updating.
 //第三步：自己现在是leader，但是分两组情况，上一次也是leader和首次变为leader
 if le.IsLeader() {
 //自己本身就是leader则不需要更新AcquireTime和LeaderTransitions
 leaderElectionRecord.AcquireTime = oldLeaderElectionRecord.AcquireTime
 leaderElectionRecord.LeaderTransitions = oldLeaderElectionRecord.LeaderTransitions
 } else {
 //首次自己变为leader则更新leader的更换次数
 leaderElectionRecord.LeaderTransitions = oldLeaderElectionRecord.LeaderTransitions + 1
 }

 //更新锁资源，这里如果在 Get 和 Update 之间有变化，将会更新失败
 // update the lock itself
 if err = le.config.Lock.Update(leaderElectionRecord); err != nil {
 klog.Errorf("Failed to update lock: %v", err)
 return false
 }

 le.observedRecord = leaderElectionRecord
 le.observedTime = le.clock.Now()
 return true
}

在这一步如果发生并发操作怎么样？

这里很重要一点就是利用到了k8s api操作的原子性：

在 le.config.Lock.Get() 中会获取到锁的对象，其中有一个 resourceVersion 字段用于标识一个资源对象的内部版本，每次更新操作都会更新其值。如果一个更新操作附加上了 resourceVersion 字段，那么 apiserver 就会通过验证当前 resourceVersion 的值与指定的值是否相匹配来确保在此次更新操作周期内没有其他的更新操作，从而保证了更新操作的原子性。

总结

leaderelection 主要是利用了k8s API操作的原子性实现了一个分布式锁，在不断的竞争中进行选举。选中为leader的进行才会执行具体的业务代码，这在k8s中非常的常见，而且我们很方便的利用这个包完成组件的编写，从而实现组件的高可用，比如部署为一个多副本的Deployment，当leader的pod退出后会重新启动，可能锁就被其他pod获取继续执行。

完整代码：https://github.com/go-demo/leaderelection

如何在Go项目中输出版本信息？

Fri, 10 Jan 2020 00:00:00 +0000

我们经常在使用CLI工具的时候，都会有这样的参数输出：

➜ ~ docker version
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:39 2019
OS/Arch: darwin/amd64
Experimental: false
➜ ~

可以打印出构建时对应的版本信息，比如 Version，Go Version，Git Commit等，这个是如何实现的呢？

实现

主要是通过ldflags参数来实现在构建的时候对变量进行赋值。

比如下面一段代码：

package main
import (
"flag"
"fmt"
"os"
)
//需要赋值的变量
var version = ""
//通过flag包设置-version参数
var printVersion bool
func init() {
flag.BoolVar(&printVersion, "version", false, "print program build version")
flag.Parse()
}
func main() {
if printVersion {
println(version)
os.Exit(0)
}
fmt.Printf("example for print version")
}

构建命令：

go build -ldflags "-X main.version=v0.1" -o example

程序输出：

➜ ./example
version=v0.1

参数说明

1、-ldflags build命令中用于调用接链接器的参数

-ldflags '[pattern=]arg list'
arguments to pass on each go tool link invocation.

2、-X 链接器参数，主要用于设置变量

-X importpath.name=value
Set the value of the string variable in importpath named name to value.
Note that before Go 1.5 this option took two separate arguments.
Now it takes one argument split on the first = sign.

一个完整的例子

这里将version包单独做了一个包存放，只需要引入即可：

package main
import (
"flag"
"github.com/go-demo/version"
)
//通过flag包设置-version参数
var printVersion bool
func init() {
flag.BoolVar(&printVersion, "version", false, "print program build version")
flag.Parse()
}
func main() {
if printVersion {
version.PrintVersion()
}
}

构建的shell如下(也可以放在Makefile中)：

#!/bin/sh
version="v0.1"
path="github.com/go-demo/version"
flags="-X $path.Version=$version -X '$path.GoVersion=$(go version)' -X '$path.BuildTime=`date +"%Y-%m-%d %H:%m:%S"`' -X $path.GitCommit=`git rev-parse HEAD`"
go build -ldflags "$flags" -o example example-version.go

TIPS: 如果值内容中含有空格，可以用单引号

最终版本输出:

➜ sh build.sh
➜ ./example -version
Version: v0.1
Go Version: go version go1.13.1 darwin/amd64
Git Commit: a775ecd27c5e78437b605c438905e9cc888fbc1c
Build Time: 2020-01-09 19:01:51

完整代码：https://github.com/go-demo/version

Kubernetes容器日志收集方案

Tue, 22 Oct 2019 00:00:00 +0000

收集POD中container日志，日志还分为两种一种是容器标准输出日志和容器内日志。

方案

从日志的采集方式上，在我看来方案大致主要分为两种：

（1）POD 里面安装logging agent

每个pod里面都要安装一个agent，无论是以放在本container还是以sidecar的方式部署，很明显会占用很多资源，基本不推荐

（2）在节点上安装logging agent（推荐）

其实容器stdout,stderr的日志最终也是落在宿主机上，而容器内的路径可以通过配置volumeMount 在宿主机上配置映射即可，所以这种方式还是最可行的

当然应用还可以自己通过代码直接上报给日志服务，但是这种方式不够通用，还增加了业务代码的复杂性

log-pilot 代码分析

这里以log-pilot为例，来分析下

代码地址： https://github.com/AliyunContainerService/log-pilot

基本流程:

监听docker-service的事件（start，restart，destory），从container信息中提取pod_name,namespace信息（可通过docker inspect [container ID]查看到），并写入filebeat中的prospector.d中的配置文件。

事件监听： pilot/pilot.go#L134

 msgs, errs := p.client.Events(ctx, options)chenqz1987, 1 year ago: • fix issue #40 and update log-pilot capability…
go func() {
defer func() {
log.Warn("finish to watch event")
p.stopChan <- true
}()
log.Info("begin to watch event")
for {
select {
case msg := <-msgs:
if err := p.processEvent(msg); err != nil {
log.Errorf("fail to process event: %v, %v", msg, err)
}
case err := <-errs:
log.Warnf("error: %v", err)
if err == io.EOF || err == io.ErrUnexpectedEOF {
return
}
msgs, errs = p.client.Events(ctx, options)
}
}
}()

对接不同收集器

log-pilot支持filebeat和fluentd两种日志收集器，目的主要是刷新对应的配置文件。主要是实现了Piloter接口：

pilot/piloter.go#L17

// Piloter interface for piloter
type Piloter interface {
Name() string
Start() error
Reload() error
Stop() error
GetBaseConf() string
GetConfHome() string
GetConfPath(container string) string
OnDestroyEvent(container string) error
}

至于在启动log-pilot选择哪种采集器进行采集，是通过在容器的entrypoint文件中通过制定环境变量PILOT_TYPE的方式进行选择性渲染的。

完善

当前最新版本[0.9.7]

1、目前log-pilot还是只能通过监听docker-servier的event进行，对于containerd，cri-o还没办法适配。

containerd目前没提供相应的event接口，可以选择从k8s api 通过List-Watch中获取

2、filebeat升级

filebeat 目前用的版本是6.1.1 ，filebeat本身就是一个比较吃资源的进程，filebeat有些issue是7820bug，可以将filebeat升级到一个新的版本。

3、资源限制

在k8s中通过制定limit，限制log-pilot的资源占用（主要还是日志采集器）

Cluster Autoscaler:集群自动扩缩容

Tue, 02 Jul 2019 00:00:00 +0000

Cluster AutoScaler 是一个自动扩展和收缩 Kubernetes 集群 Node 的扩展。当集群容量不足时，它会自动去 Cloud Provider （支持 GCE、GKE 和 AWS）创建新的 Node，而在 Node 长时间资源利用率很低时自动将其删除以节省开支。

在Kubernetes中关于弹性伸缩主要有三种格式：

HPA：Horizontal Pod Autoscaling可以根据CPU利用率自动伸缩一个Replication Controller、Deployment 或者Replica Set中的Pod数量
VPA：Vertical Pod Autoscaler（VPA）使用户无需为其pods中的容器设置最新的资源request。配置后，它将根据使用情况自动设置request，从而允许在节点上进行适当的调度，以便为每个pod提供适当的资源量。
CA：自动伸缩NODE节点

部署

Cluster Autoscaler代码地址：https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

CA 提供了Cloud Provider接口供各个云厂商接入，主要是针对厂商自己的API，应对节点添加以及删除的请求。

目前云厂商的ECS产品都会有扩缩容的功能（例如阿里云ESS，就是CA中伸缩组的概念），CA就可以结合ESS完成集群的扩缩容功能。

各大厂商节点扩缩容安装：

以阿里云为例，具体安装可以参考这篇文章：阿里云上弹性伸缩kubernetes集群 - autoscaler

其中关键yaml文件如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: cluster-autoscaler
namespace: kube-system
labels:
app: cluster-autoscaler
spec:
replicas: 1
selector:
matchLabels:
app: cluster-autoscaler
template:
metadata:
labels:
app: cluster-autoscaler
spec:
serviceAccountName: admin
containers:
- image: registry.cn-hangzhou.aliyuncs.com/google-containers/cluster-autoscaler:v1.1.0
name: cluster-autoscaler
resources:
limits:
cpu: 100m
memory: 300Mi
requests:
cpu: 100m
memory: 300Mi
command:
- ./cluster-autoscaler
- --v=4
- --stderrthreshold=info
- --cloud-provider=alicloud
- --skip-nodes-with-local-storage=false
- --nodes=1:100:${AUTO_SCALER_GROUP}
env:
- name: ACCESS_KEY_ID
valueFrom:
secretKeyRef:
name: cloud-config
key: access-key-id
- name: ACCESS_KEY_SECRET
valueFrom:
secretKeyRef:
name: cloud-config
key: access-key-secret
imagePullPolicy: "Always"

其中 --nodes=1:100:${AUTO_SCALER_GROUP}参数，表示扩容最大100个，缩容最小1个节点，后面${AUTO_SCALER_GROUP}表示伸缩组ID

工作原理

扩容

CA会定期(默认10s,通过参数--scan-interval设置)检测当前集群状态下是否存在pending的pod，然后经过计算，判断需要扩容几个节点，最终从node group中进行节点的扩容：

Node Group 就对应伸缩组的概念，可以支持配置支持多个伸缩组，通过策略来进行选择，目前支持的策略为：

random：随机选择
most-pods：选择能够创建pod最多的Node Group
least-waste：以最小浪费原则选择，即选择有最少可用资源的 Node Group
price：根据主机的价格选择，选择最便宜的
priority：根据优先级进行选择，通过配置cluster-autoscaler-priority-expander configMap，具体参考：https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/expander/priority

缩容

集群缩容其实是一个可选的选项，通过参数--scale-down-enabled控制是否开启缩容。

CA定期会检测集群状态，判断当前集群状态下，哪些节点资源利用率小于50%(通过参数--scale-down-utilization-threshold控制)。

资源利用率计算是通过判断集群cpu，mem 中request值占用率计算的，只要有一个指标超了就可能会出发缩容，之所以说是可能会触发扩容，是因为要保证被驱逐节点上的POD能够正确调度到其他节点上。

哪些NODE不会缩容：

当您设置了严格的 PodDisruptionBudget 的 Pod 不满足 PDB 时，不会缩容。
Kube-system 下的 Pod。通过参数--skip-nodes-with-system-pods控制
节点上有非 deployment，replica set，job，stateful set 等控制器创建的 Pod。
Pod 有本地存储。通过参数--skip-nodes-with-local-storage控制
Pod 不能被调度到其他节点上。例如资源不满足等

实现Cluster Provider

如果你使用的以上主流的几个云厂商的主机资源/k8s集群，可以直接使用官方的CA版本，只需要通过参数--cloud-provider控制来自哪个云厂商就可以。

如果想要对接自己的IaaS层，只需要实现其中的接口就可以了，接口定义如下：

// CloudProvider contains configuration info and functions for interacting with
// cloud provider (GCE, AWS, etc).
type CloudProvider interface {Marcin Wielgus, 3 years ago: • Cluster-autoscaler: cloud provider interface
// Name returns name of the cloud provider.
Name() string
// NodeGroups returns all node groups configured for this cloud provider.
//返回所有伸缩组
NodeGroups() []NodeGroup
// NodeGroupForNode returns the node group for the given node, nil if the node
// should not be processed by cluster autoscaler, or non-nil error if such
// occurred. Must be implemented.
NodeGroupForNode(*apiv1.Node) (NodeGroup, error)
// Pricing returns pricing model for this cloud provider or error if not available.
// Implementation optional.
Pricing() (PricingModel, errors.AutoscalerError)
// GetAvailableMachineTypes get all machine types that can be requested from the cloud provider.
// Implementation optional.
GetAvailableMachineTypes() ([]string, error)
// NewNodeGroup builds a theoretical node group based on the node definition provided. The node group is not automatically
// created on the cloud provider side. The node group is not returned by NodeGroups() until it is created.
// Implementation optional.
NewNodeGroup(machineType string, labels map[string]string, systemLabels map[string]string,
taints []apiv1.Taint, extraResources map[string]resource.Quantity) (NodeGroup, error)
// GetResourceLimiter returns struct containing limits (max, min) for resources (cores, memory etc.).
GetResourceLimiter() (*ResourceLimiter, error)
// GPULabel returns the label added to nodes with GPU resource.
GPULabel() string
// GetAvailableGPUTypes return all available GPU types cloud provider supports.
GetAvailableGPUTypes() map[string]struct{}
// Cleanup cleans up open resources before the cloud provider is destroyed, i.e. go routines etc.
Cleanup() error
// Refresh is called before every main loop and can be used to dynamically update cloud provider state.
// In particular the list of node groups returned by NodeGroups can change as a result of CloudProvider.Refresh().
Refresh() error
}

其中NodeGroup接口定义：

// NodeGroup contains configuration info and functions to control a set
// of nodes that have the same capacity and set of labels.
type NodeGroup interface {
// MaxSize returns maximum size of the node group.
MaxSize() int
// MinSize returns minimum size of the node group.
MinSize() int
// TargetSize returns the current target size of the node group. It is possible that the
// number of nodes in Kubernetes is different at the moment but should be equal
// to Size() once everything stabilizes (new nodes finish startup and registration or
// removed nodes are deleted completely). Implementation required.
TargetSize() (int, error)
// IncreaseSize increases the size of the node group. To delete a node you need
// to explicitly name it and use DeleteNode. This function should wait until
// node group size is updated. Implementation required.
//扩容伸缩组
IncreaseSize(delta int) error
// DeleteNodes deletes nodes from this node group. Error is returned either on
// failure or if the given node doesn't belong to this node group. This function
// should wait until node group size is updated. Implementation required.
//从伸缩组中删除节点
DeleteNodes([]*apiv1.Node) error
// DecreaseTargetSize decreases the target size of the node group. This function
// doesn't permit to delete any existing node and can be used only to reduce the
// request for new nodes that have not been yet fulfilled. Delta should be negative.
// It is assumed that cloud provider will not delete the existing nodes when there
// is an option to just decrease the target. Implementation required.
DecreaseTargetSize(delta int) error
// Id returns an unique identifier of the node group.
Id() string
// Debug returns a string containing all information regarding this node group.
Debug() string
// Nodes returns a list of all nodes that belong to this node group.
// It is required that Instance objects returned by this method have Id field set.
// Other fields are optional.
Nodes() ([]Instance, error)
// TemplateNodeInfo returns a schedulernodeinfo.NodeInfo structure of an empty
// (as if just started) node. This will be used in scale-up simulations to
// predict what would a new node look like if a node group was expanded. The returned
// NodeInfo is expected to have a fully populated Node object, with all of the labels,
// capacity and allocatable information as well as all pods that are started on
// the node by default, using manifest (most likely only kube-proxy). Implementation optional.
TemplateNodeInfo() (*schedulernodeinfo.NodeInfo, error)
// Exist checks if the node group really exists on the cloud provider side. Allows to tell the
// theoretical node group from the real one. Implementation required.
Exist() bool
// Create creates the node group on the cloud provider side. Implementation optional.
Create() (NodeGroup, error)
// Delete deletes the node group on the cloud provider side.
// This will be executed only for autoprovisioned node groups, once their size drops to 0.
// Implementation optional.
Delete() error
// Autoprovisioned returns true if the node group is autoprovisioned. An autoprovisioned group
// was created by CA and can be deleted when scaled to 0.
Autoprovisioned() bool
}

其中IncreaseSize，IncreaseSize才是关键的方法，分别对用扩容伸缩组和增加节点。

在调用IncreaseSize接口后，需要完成节点自动添加进集群。参考阿里云是通过配置shell脚本到伸缩组中的ECS启动脚本中，当ECS启动，自动执行该脚本。当然我们也可以自定义通过其他方式加入集群。

k8s网络组件：calico

Fri, 12 Oct 2018 00:00:00 +0000

前提已经安装好k8s集群

安装

calico 安装其实很简单，已经集成在两个yaml文件中

calico 版本: v3.2.3

安装必看

如果安装过flannel组件，需要先去除docker启动项中 $DOCKER_NETWORK_OPTIONS参数
删除已有的/etc/cni/net.d，/opt/cni/bin文件
kubelet和kube-apiserver启动项中需要加上--allow-privileged=true，保证calico-node需要以特权模式运行
这里calico文件采用了CrossSubnet模式

指定k8s使用CNI插件

在kubelet启动参数中加入以下参数:

--network-plugin=cni: 指定使用cni插件
--cni-bin-dir=/opt/cni/bin：存放网络配置的可执行文件
--cni-conf-dir=/etc/cni/net.d: 存放网络配置文件，如果有多个文件，则只会选择一个(根据文件名排序)

部署

安装文件放在: https://github.com/silenceper/k8s-install/tree/master/calico

主要包含两个文件calico.yaml，rbac.yaml:

需要做如下参数修改：

将其中的ETCD_LVS_HOST修改为集群的etcd地址，并且将TLS_ETCD_KEY,TLS_ETCD_CERT ,TLS_ETCD_CA替换为证书的内容的base64后的结果：

# 其中证书的路径根据自己环境更改为正确的路径
TLS_ETCD_CA=$(cat /etc/kubernetes/ssl/ca.pem | base64 |tr -d "\n")
TLS_ETCD_KEY=$(cat /etc/kubernetes/ssl/etcd-key.pem | base64 |tr -d "\n")
TLS_ETCD_CERT=$(cat /etc/kubernetes/ssl/etcd.pem | base64 |tr -d "\n")
# 替换内容
sed -i "s#TLS_ETCD_CA#$TLS_ETCD_CA#g" calico.yaml
sed -i "s#TLS_ETCD_CERT#$TLS_ETCD_CERT#g" calico.yaml
sed -i "s#TLS_ETCD_KEY#$TLS_ETCD_KEY#g" calico.yaml
# 替换ETCD_LVS_HOST地址，更换为自己的etcd地址
sed -i "s#ETCD_LVS_HOST#192.168.99.101#g" calico.yaml

部署

kubectl apply -f calico.yaml
kubectl apply -f rbac.yaml

calicoctl 安装

calicoctl 工具，主要用来配置calico，例如配置calico 网络模式等

下载地址：https://github.com/projectcalico/calicoctl/releases

将下载和二进制文件放在/usr/local/bin目录下

calicoctl 配置文件

将以下内容写入文件/etc/calico/calicoctl.cfg:

apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
etcdEndpoints: https://192.168.99.101:2379
etcdKeyFile: /etc/kubernetes/ssl/kubernetes-key.pem
etcdCertFile: /etc/kubernetes/ssl/kubernetes.pem
etcdCACertFile: /etc/kubernetes/ssl/ca.pem

测试成功：

[root@192-168-99-101 calico]# calicoctl get node -o wide
NAME ASN IPV4 IPV6
192-168-99-101 (unknown) 192.168.99.101/24
192-168-99-102 (unknown) 192.168.99.102/24

###修改ipipMode

ipipMode有三种：

Never： bgp模式
Always：IPIP模式
CrossSubnet：自动选择，同一网段选择bgp模式，跨网段IPIP模式

通过calicoctl get ippool -o yaml命令可以查看到当前使用的ipipMode为CrossSubnet，通过如下方式可以修改：

calictl apply -f ippool.yaml

其中ippool.yaml文件内容：

apiVersion: projectcalico.org/v3
items:
- apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
name: default-ipv4-ippool
spec:
cidr: 172.23.0.0/16
ipipMode: Always
natOutgoing: true
kind: IPPoolList

k8s网络组件：flannel

Wed, 26 Sep 2018 00:00:00 +0000

Flannel是一个专门为k8s定制的网络解决方案，主要解决POD跨主机通信问题，这里主要讲述Flannel是如何实现的。

安装

集成在k8s上有两种方式，一种是利用etcd存储整个集群的网络配置，另外一种是利用kubernetes的api 获取网络配置信息，分别如下：

ETCD 方式

这种方式在前面的k8s集群安装-安装Flannel网络插件已经介绍过，就是利用etcd存储网络配置信息，并且利用dockerd启动参数--bip来指定每个节点的网段信息，我们指定vxlan作为数据传输的backend。

CNI插件方式

这种方式是利用cni插件，并且将网络配置信息存储在kubernetes api中：

配置网段

在kube-controller-manager启动脚本中加入--allocate-node-cidrs=true，--cluster-cidr=10.244.0.0/16 参数。

10.244.0.0/16为我们指定的集群的网段，这样每一个docker节点都会分别使用自网段10.244.0.0/24，10.244.1.0/24作为每个pod的网段，可以通过kubectl get pod 192.168.99.101 -o yaml命令查看spec.podCIDR字段。

如果不配置该步骤可能会flannel出现error registering network: failed to acquire lease: node "192.168.99.101" pod的错误

指定kublet网络插件

在kubelet中指定三个参数

--network-plugin=cni : 网络插件使用cni
--cni-conf-dir=/etc/cni/net.d cni配置文件，默认
--cni-bin-dir=/opt/cni/bin cni可执行文件，默认

这样在kublet启动的时候，就会去/etc/cni/net.d目录查找配置文件，并解析，使用相应的插件配置网络

下载cni依赖插件

下载cni官方提供的组件：cni-plugins-amd64-v0.7.1.tgz ，并将可执行文件放在/opt/cni/bin目录。

这里不单单只会用到flannel文件，也会用到brage用来创建网桥以及host-local用来分配ip

安装flanneld组件

flannel组件直接以daemonset的方式安装在k8s集群中：

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

其中kube-flannel-cfgconfigmap中的Network字段需要与--cluster-cidr配置的网段一致。

这一步主要是安装了flanneld以及将flannel配置文件写入/etc/cni/net.d目录

查看kube-flannel.yml中flanneld的启动参数为：

--ip-masq : 需要为其配置SNAT
--kube-subnet-mgr : 代表其使用kube类型的subnet-manager。该类型有别于使用etcd的local-subnet-mgr类型，使用kube类型后，flannel上各Node的IP子网分配均基于K8S Node的spec.podCIDR属性

我的是多网卡的机器，发现网络不通，所以我特别指定的flanneld用来对外通信的网卡增加–iface 参数，指定可以进行外部通信的网卡

区别

flanneld 容器化了
flanneld 网段信息来源于kubernetes api，而不依赖etcd

原理

以上两种方式的对比可以发现，通过cni方式安装的flannel会多一个cni0的网桥，其实这个与docker0网桥的作用是一样的，创建了一对veth pair 分别联通容器内部与主机网络，并把其中一端接入cni0网桥。

整个通信过程如图：

图中的ip信息与本机不一致，主要说明通信过程

容器内部->docker0->flanneld->网络传输->对端flanneld->对端docker0->对端容器内

当数据包到吧flanneld后支持多种backend进行转发

Flannel backend

Host-gw: 同一网段直接通信，速度快
udp：用户空间的udp封装
vxlan: 利用内核vxlan协议进行传输
aws vpc: 利用aws平台内部提供的功能进行传输

如何选择？

vxlan在功能上，和性能上基本满足我们的要求，可以直接跨网段间通信，同时性能上又比udp的方式高效

k8s源码阅读(一)：源码结构

Wed, 12 Sep 2018 11:45:59 +0800

环境

k8s代码版本：release-1.9
工具：vscode, dlv

下载代码，并放入gopath中，方便编译：

$ mkdir -p $GOPATH/src/k8s.io && cd $GOPATH/src/k8s.io
$ git clone https://github.com/kubernetes/kubernetes # 有墙

代码结构

├── Godeps godep依赖文件
├── api swagger api文档
├── build 构建用到的命令
├── cluster 自动构建和快速构建k8s集群的脚本(进入维护阶段)
├── cmd 核心：命令入口
├── docs 文档
├── examples 一些部署样例yaml文件
├── hack hack代码
├── logo logo图片
├── pkg 核心：具体命令的逻辑代码
├── plugin 主要是kube-scheduler
├── staging 暂存区，用于分离仓库
├── test test
├── third_party 一些第三方工具
├── translations 多语言文件
└── vendor 依赖代码

组件入口基本都在/cmd/目录下，并且可直接通过go build单独编译（通过make xxxx也行，make help查看具体指令）

DLV调试阅读

有两种方式，一种是直接通过dlv命令进行调试，比如调试kubelet组件：

$ cd cmd/kubelet
$ dlv debug . -- --logtostderr=true --v=5 --address=192.168.99.102 --hostname-override=192.168.99.102 --allow-privileged=true --bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --cert-dir=/etc/kubernetes/ssl --cluster-domain=cluster.local --hairpin-mode promiscuous-bridge --serialize-image-pulls=false

其中--后为程序运行参数

进入之后为通过break，n,s,p等指令操作，这种方式不太方便，尤其对于k8s这种大工程，推荐配合工具进行，比如vscode。

通过我配置launch.json文件的args参数，让kubelet运行起来：

"args": [
"--address=192.168.186.219",
"--hostname-override=192.168.186.219",
"--cluster-domain=cluster.local",
"--root-dir=/Users/silenceper/workspace/golang/src/k8s.io/kubelet",
"--bootstrap-kubeconfig=/Users/silenceper/workspace/golang/src/k8s.io/kubelet/kubernetes/bootstrap.kubeconfig",
"--kubeconfig=/Users/silenceper/workspace/golang/src/k8s.io/kubelet/kubernetes/kubelet.kubeconfig",
"--cert-dir=/Users/silenceper/workspace/golang/src/k8s.io/kubelet/kubernetes/ssl",
],

通过调试，可以做到边看代码，变追踪kubelet的执行过程

因为os的原因，执行流程可能与目标平台的执行结果可能不一致，不过可以手动改代码达到预期结果，或者直接在Linux下调试

docker pull 翻墙下载镜像

Sun, 09 Sep 2018 11:45:59 +0800

我们一般通过设置http_proxy环境变量，使得http请求，可以走我们设置的proxy，（一些go get镜像无法下载可以这么用），但是对于docker pull命令是不生效的，因为systemd引导启动的service默认不会读取这些变量，所以我们可以通过在service文件中加入环境变量解决：

设置变量 http_proxy

主要是通过在docker启动的时候指定HTTP_PROXY ，HTTPS_PROXY。

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/" "HTTPS_PROXY=http://proxy.example.com:80/""NO_PROXY=localhost,127.0.0.1,docker-registry.somecorporation.com"

其中NO_PROXY变量指的是那些http请求不走代理。

下面两种都是一样的效果，推荐方式二，可以避免直接修改docker.service文件，防止升级之后文件覆盖。

方式一：直接修改docker.service 文件

docker service文件/usr/lib/systemd/system/docker.service，在Service段配置中加入。

方式二：通过override.conf文件(推荐)

文件路径： /etc/systemd/system/docker.service.d/override.conf

可以直接通过systemctl edit docker打开文件进行编辑，加入上述配置，重启生效。

这种方式来之 @Feng_Yu的提醒，THK

重启docker

systemctl daemon-reload
systemctl restart docker

TIPS: polipo 可以将socks5协议转换成http代理。

参考资料

https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

在CentOS上搭建Kubernetes集群

Fri, 07 Sep 2018 11:45:59 +0800

以下是我自己在部署k8s集群上做的一些记录，部署了一个master，一个node节点。

环境准备

我在VirtualBox中建的两个CentOS容器，并且互通：

IP	系统	角色	配置
192.168.99.101	CentOS 7.5.1804	master	1核2G
192.168.99.102	CentOS 7.5.1804	node	1核2G

安装版本：

组件	版本
Kubernetes	1.10.7
Etcd	3.1.10
Docker	17.12.1-ce

证书准备

使用CFSSL工具进行证书生成

CA证书和秘钥文件主要用来做传输加密用的，将会生成如下文件：

ca-key.pem
ca.pem
kubernetes-key.pem
kubernetes.pem
kube-proxy.pem
kube-proxy-key.pem
admin.pem
admin-key.pem

使用证书的组件如下：

etcd：使用 ca.pem、kubernetes-key.pem、kubernetes.pem；
kube-apiserver：使用 ca.pem、kubernetes-key.pem、kubernetes.pem；
kubelet：使用 ca.pem；
kube-proxy：使用 ca.pem、kube-proxy-key.pem、kube-proxy.pem；
kubectl：使用 ca.pem、admin-key.pem、admin.pem；
kube-controller-manager：使用 ca-key.pem、ca.pem

在master节点上进行操作：

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
chmod +x cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
chmod +x cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo
export PATH=/usr/local/bin:$PATH

创建ca证书

创建 ca-config.json文件：

{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "87600h"
}
}
}
}

创建 ca-csr.json文件：

{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
],
"ca": {
"expiry": "87600h"
}
}

生成ca证书和私钥

cfssl gencert -initca ca-csr.json | cfssljson -bare ca

生成kubernetes证书

创建kubernetes-csr.json文件：

{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"192.168.99.101",
"192.168.99.102",
"10.254.0.1",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}

其中ip段改为自己的ip，包括etcd集群IP，k8s master集群ip，k8s服务的服务ip(一般是 kube-apiserver 指定的 service-cluster-ip-range 网段的第一个IP，如 10.254.0.1)

生成证书和私钥：

[root@localhost ssl]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes

创建admin证书

创建 admin-csr.json文件：

{
"CN": "admin",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "system:masters",
"OU": "System"
}
]
}

生成证书

[root@localhost ssl]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin

创建kube-proxy证书

创建kube-proxy-csr.json文件：

{
"CN": "system:kube-proxy",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}

生成命令：

[root@localhost ssl]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy

分发证书

将生成的证书和秘钥文件（后缀为.pem）拷贝到所有机器的/etc/kubernetes/ssl 目录下

命令略

安装kubectl文件

wget -c https://dl.k8s.io/v1.10.7/kubernetes-client-darwin-386.tar.gz
tar -xzvf kubernetes-client-linux-amd64.tar.gz
cp kubernetes/client/bin/kube* /usr/bin/
chmod a+x /usr/bin/kube*

创建 kubectl kubeconfig 文件

export KUBE_APISERVER="https://192.168.99.101:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ssl/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER}
# 设置客户端认证参数
kubectl config set-credentials admin \
--client-certificate=/etc/kubernetes/ssl/admin.pem \
--embed-certs=true \
--client-key=/etc/kubernetes/ssl/admin-key.pem
# 设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=admin
# 设置默认上下文
kubectl config use-context kubernetes

admin 证书中设定了 group=system:masters即（O=system:masters）这个group与ckuster-admin ClusterRole绑定，所以具有整个集群的权限如果需要单独指定权限，则可以自己设定user绑定ClusterRole

创建 kubeconfig 文件

创建 TLS Bootstrapping Token

$ export BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')
$ cat > token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF
$ cp token.csv /etc/kubernetes/

创建 kubelet bootstrapping kubeconfig 文件

cd /etc/kubernetes
export KUBE_APISERVER="https://192.168.99.101:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ssl/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=bootstrap.kubeconfig
# 设置客户端认证参数
kubectl config set-credentials kubelet-bootstrap \
--token=${BOOTSTRAP_TOKEN} \
--kubeconfig=bootstrap.kubeconfig
# 设置上下文参数
kubectl config set-context default \
--cluster=kubernetes \
--user=kubelet-bootstrap \
--kubeconfig=bootstrap.kubeconfig
# 设置默认上下文
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig

创建 kube-proxy kubeconfig 文件

export KUBE_APISERVER="https://192.168.99.101:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ssl/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=kube-proxy.kubeconfig
# 设置客户端认证参数
kubectl config set-credentials kube-proxy \
--client-certificate=/etc/kubernetes/ssl/kube-proxy.pem \
--client-key=/etc/kubernetes/ssl/kube-proxy-key.pem \
--embed-certs=true \
--kubeconfig=kube-proxy.kubeconfig
# 设置上下文参数
kubectl config set-context default \
--cluster=kubernetes \
--user=kube-proxy \
--kubeconfig=kube-proxy.kubeconfig
# 设置默认上下文
kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

分发kubeconfig文件

将两个 kubeconfig 文件分发到所有 Node 机器的 /etc/kubernetes/ 目录

cp bootstrap.kubeconfig kube-proxy.kubeconfig /etc/kubernetes/

Etcd安装

我这里为了简单，ETCD节点只用了一个，并且安装在了master节点上，多个也是一样的，只是在--initial-cluster选择中将其他节点ip填入进去。

下载ETCD:

$ wget -c https://github.com/coreos/etcd/releases/download/v3.1.10/etcd-v3.1.10-linux-amd64.tar.gz
$ tar -zxvf etcd-v3.1.10-linux-amd64.tar.gz
$ mv etcd-v3.1.10-linux-amd64/etcd* /usr/local/bin

创建 etcd 的 systemd unit 文件

vim /usr/lib/systemd/system/etcd.service

内容如下：

[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/usr/local/bin/etcd \
--name ${ETCD_NAME} \
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \
--peer-cert-file=/etc/kubernetes/ssl/kubernetes.pem \
--peer-key-file=/etc/kubernetes/ssl/kubernetes-key.pem \
--trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--initial-advertise-peer-urls ${ETCD_INITIAL_ADVERTISE_PEER_URLS} \
--listen-peer-urls ${ETCD_LISTEN_PEER_URLS} \
--listen-client-urls ${ETCD_LISTEN_CLIENT_URLS},http://127.0.0.1:2379 \
--advertise-client-urls ${ETCD_ADVERTISE_CLIENT_URLS} \
--initial-cluster-token ${ETCD_INITIAL_CLUSTER_TOKEN} \
--initial-cluster infra1=https://192.168.99.101:2380 \
--initial-cluster-state new \
--data-dir=${ETCD_DATA_DIR}
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

创建/etc/etcd/etcd.conf文件:

# [member]
ETCD_NAME=infra1
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="https://192.168.99.101:2380"
ETCD_LISTEN_CLIENT_URLS="https://192.168.99.101:2379"
#[cluster]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.99.101:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.99.101:2379"

启动服务：

mv etcd.service /usr/lib/systemd/system/
mkdir /var/lib/etcd
systemctl daemon-reload
systemctl enable etcd
systemctl start etcd
systemctl status etcd

验证服务：

etcdctl --ca-file=/etc/kubernetes/ssl/ca.pem --cert-file=/etc/kubernetes/ssl/kubernetes.pem --key-file=/etc/kubernetes/ssl/kubernetes-key.pem cluster-health
2018-09-07 15:41:30.782777 I | warning: ignoring ServerName for user-provided CA for backwards compatibility is deprecated
2018-09-07 15:41:30.783295 I | warning: ignoring ServerName for user-provided CA for backwards compatibility is deprecated
member 171ef35542ebf92b is healthy: got healthy result from https://192.168.99.101:2379
cluster is healthy

cluster is healthy 表示成功。

Master节点部署

master节点上主要是三个组件：

kube-apiserver
kube-scheduler
kube-controller-manager

同事只能又一个kube-scheduler,kube-controller-manager进程处于工作状态，如果运行多个，则需要通过选举产生一个leader。

下载server包：

wget -c https://dl.k8s.io/v1.10.7/kubernetes-server-linux-amd64.tar.gz
tar -xzvf kubernetes-server-linux-amd64.tar.gz
cd kubernetes
tar -xzvf kubernetes-src.tar.gz

将二进制文件拷贝到指定路径

cp -r server/bin/{kube-apiserver,kube-controller-manager,kube-scheduler} /usr/local/bin/

同时将 server/bin/目录下的kube-proxy,kubelet 三个文件复制到node节点的 /usr/local/bin/ 目录

配置和启动 kube-apiserver

创建 /etc/kubernetes/config文件:

###
# kubernetes system config
#
# The following values are used to configure various aspects of all
# kubernetes services, including
#
# kube-apiserver.service
# kube-controller-manager.service
# kube-scheduler.service
# kubelet.service
# kube-proxy.service
# logging to stderr means we get it in the systemd journal
KUBE_LOGTOSTDERR="--logtostderr=true"
# journal message level, 0 is debug
KUBE_LOG_LEVEL="--v=0"
# Should this cluster be allowed to run privileged docker containers
KUBE_ALLOW_PRIV="--allow-privileged=true"
# How the controller-manager, scheduler, and proxy find the apiserver
KUBE_MASTER="--master=http://192.168.99.101:8080"

创建service文件/usr/lib/systemd/system/kube-apiserver.service：

[Unit]
Description=Kubernetes API Service
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target
After=etcd.service
[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/apiserver
ExecStart=/usr/local/bin/kube-apiserver \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBE_ETCD_SERVERS \
$KUBE_API_ADDRESS \
$KUBE_API_PORT \
$KUBELET_PORT \
$KUBE_ALLOW_PRIV \
$KUBE_SERVICE_ADDRESSES \
$KUBE_ADMISSION_CONTROL \
$KUBE_API_ARGS
Restart=on-failure
Type=notify
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

apiserver的配置文件 /etc/kubernetes/apiserver:

###
## kubernetes system config
##
## The following values are used to configure the kube-apiserver
##
#
## The address on the local server to listen to.
KUBE_API_ADDRESS="--advertise-address=192.168.99.101 --bind-address=192.168.99.101 --insecure-bind-address=192.168.99.101"
#
## The port on the local server to listen on.
#KUBE_API_PORT="--port=8080"
#
## Port minions listen on
#KUBELET_PORT="--kubelet-port=10250"
#
## Comma separated list of nodes in the etcd cluster
KUBE_ETCD_SERVERS="--etcd-servers=https://192.168.99.101:2379"
#
## Address range to use for services
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
#
## default admission control policies
KUBE_ADMISSION_CONTROL="--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota"
#
## Add your own!
KUBE_API_ARGS="--authorization-mode=Node,RBAC --runtime-config=rbac.authorization.k8s.io/v1beta1 --kubelet-https=true --enable-bootstrap-token-auth --token-auth-file=/etc/kubernetes/token.csv --service-node-port-range=30000-32767 --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem --client-ca-file=/etc/kubernetes/ssl/ca.pem --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem --etcd-cafile=/etc/kubernetes/ssl/ca.pem --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem --enable-swagger-ui=true --apiserver-count=3 --audit-log-maxage=30 --audit-log-maxbackup=3 --audit-log-maxsize=100 --audit-log-path=/var/lib/audit.log --event-ttl=1h"

启动kube-apiserver:

systemctl daemon-reload
systemctl enable kube-apiserver
systemctl start kube-apiserver
systemctl status kube-apiserver

配置和启动 kube-controller-manager

创建 /usr/lib/systemd/system/kube-controller-manager.service文件：

[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/controller-manager
ExecStart=/usr/local/bin/kube-controller-manager \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBE_MASTER \
$KUBE_CONTROLLER_MANAGER_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

配置文件：/etc/kubernetes/controller-manager

###
# The following values are used to configure the kubernetes controller-manager
# defaults from config and apiserver should be adequate
# Add your own!
KUBE_CONTROLLER_MANAGER_ARGS="--address=127.0.0.1 --service-cluster-ip-range=10.254.0.0/16 --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.pem --cluster-signing-key-file=/etc/kubernetes/ssl/ca-key.pem --service-account-private-key-file=/etc/kubernetes/ssl/ca-key.pem --root-ca-file=/etc/kubernetes/ssl/ca.pem --leader-elect=true"

启动 kube-controller-manager:

systemctl daemon-reload
systemctl enable kube-controller-manager
systemctl start kube-controller-manager
systemctl status kube-controller-manager

配置和启动 kube-scheduler

创建/usr/lib/systemd/system/kube-scheduler.service文件：

[Unit]
Description=Kubernetes Scheduler Plugin
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/scheduler
ExecStart=/usr/local/bin/kube-scheduler \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBE_MASTER \
$KUBE_SCHEDULER_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

/etc/kubernetes/scheduler文件：

###
# kubernetes scheduler config
# default config should be adequate
# Add your own!
KUBE_SCHEDULER_ARGS="--leader-elect=true --address=127.0.0.1"

启动 kube-scheduler:

systemctl daemon-reload
systemctl enable kube-scheduler
systemctl start kube-scheduler
systemctl status kube-scheduler

验证master节点

[root@localhost ~]# kubectl get componentstatuses
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}

安装Flannel网络插件

Flannel网络插件只需要安装在node节点上就好了，他主要作用是将不同node上的pod网络联通，所以我们在102这台机器上操作：

使用yum直接安装:

yum install -y flannel

创建 /usr/lib/systemd/system/flanneld.service文件：

[Unit]
Description=Flanneld overlay address etcd agent
After=network.target
After=network-online.target
Wants=network-online.target
After=etcd.service
Before=docker.service
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/flanneld
EnvironmentFile=-/etc/sysconfig/docker-network
ExecStart=/usr/bin/flanneld-start \
-etcd-endpoints=${FLANNEL_ETCD_ENDPOINTS} \
-etcd-prefix=${FLANNEL_ETCD_PREFIX} \
$FLANNEL_OPTIONS
ExecStartPost=/usr/libexec/flannel/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/docker
Restart=on-failure
[Install]
WantedBy=multi-user.target
RequiredBy=docker.service

/etc/sysconfig/flanneld文件：

# Flanneld configuration options
# etcd url location. Point this to the server where etcd runs
FLANNEL_ETCD_ENDPOINTS="https://192.168.99.101:2379"
# etcd config key. This is the configuration key that flannel queries
# For address range assignment
FLANNEL_ETCD_PREFIX="/kube-centos/network"
# Any additional options that you want to pass
FLANNEL_OPTIONS="-etcd-cafile=/etc/kubernetes/ssl/ca.pem -etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem -etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem"

在etcd中创建网络配置，在master节点上操作就好了，省得指定endpoints:

$ etcdctl --ca-file=/etc/kubernetes/ssl/ca.pem --cert-file=/etc/kubernetes/ssl/kubernetes.pem --key-file=/etc/kubernetes/ssl/kubernetes-key.pem mkdir /kube-centos/network
$ etcdctl --ca-file=/etc/kubernetes/ssl/ca.pem --cert-file=/etc/kubernetes/ssl/kubernetes.pem --key-file=/etc/kubernetes/ssl/kubernetes-key.pem mk /kube-centos/network/config '{"Network":"172.30.0.0/16","SubnetLen":24,"Backend":{"Type":"vxlan"}}'

启动flannel

systemctl daemon-reload
systemctl enable flanneld
systemctl start flanneld
systemctl status flanneld

Docker安装

下载并安装：

wget -c https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-17.12.1.ce-1.el7.centos.x86_64.rpm
yum install docker-ce-17.12.1.ce-1.el7.centos.x86_64.rpm

在/usr/lib/systemd/system/docker.service文件中增加一个环境变量：

EnvironmentFile=-/run/flannel/docker

并且启动命令为，主要是增加了一个$DOCKER_NETWORK_OPTIONS参数是flannel传入的用来修改docker0网桥IP

ExecStart=/usr/bin/dockerd $DOCKER_NETWORK_OPTIONS --log-driver=json-file --log-opt max-size=50m --log-opt max-file=5

启动：

systemctl daemon-reload
systemctl enable docker
systemctl start docker
systemctl status docker

Node节点部署

kube-proxy，kubelet 文件在kubernetes-server-linux-amd64.tar.gz，复制到/usr/local/bin目录

安装配置kubelet

前提：关闭swap，否则无法启动使用:swapoff -a或者注释fstab中swap配置

TIPS: 现在master节点上，赋予kubelet-bootstrap用户，system:node-bootstrapper cluster 角色，否则kubelet没有权限创建认证请求。

cd /etc/kubernetes
kubectl create clusterrolebinding kubelet-bootstrap \
--clusterrole=system:node-bootstrapper \
--user=kubelet-bootstrap

文件/usr/lib/systemd/system/kubelet.service：

[Unit]
Description=Kubernetes Kubelet Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=docker.service
Requires=docker.service
[Service]
WorkingDirectory=/var/lib/kubelet
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/kubelet
ExecStart=/usr/local/bin/kubelet \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBELET_ADDRESS \
$KUBELET_HOSTNAME \
$KUBE_ALLOW_PRIV \
$KUBELET_ARGS
Restart=on-failure
[Install]
WantedBy=multi-user.target

同时配置/etc/kubernetes/kubelet文件：

###
## kubernetes kubelet (minion) config
#
## The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
KUBELET_ADDRESS="--address=192.168.99.102"
#
## You may leave this blank to use the actual hostname
KUBELET_HOSTNAME="--hostname-override=192.168.99.102"
KUBELET_ARGS="--bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --cert-dir=/etc/kubernetes/ssl --cluster-domain=cluster.local --hairpin-mode promiscuous-bridge --serialize-image-pulls=false"

启动：

mkdir /varlib/kubelet
systemctl daemon-reload
systemctl enable kubelet
systemctl start kubelet
systemctl status kubelet

通过kublet的TLS证书请求

[root@localhost kubernetes]# kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-vtB-rALjRudPIp4IvIHwOTOggoJC-213GpvDoYVqQlA 18s kubelet-bootstrap Pending

通过 CSR 请求:

[root@localhost kubernetes]# kubectl certificate approve node-csr-vtB-rALjRudPIp4IvIHwOTOggoJC-213GpvDoYVqQlA
certificatesigningrequest.certificates.k8s.io "node-csr-vtB-rALjRudPIp4IvIHwOTOggoJC-213GpvDoYVqQlA" approved

配置 kube-proxy

安装conntrack：

yum install -y conntrack-tools

文件/usr/lib/systemd/system/kube-proxy.service：

[Unit]
Description=Kubernetes Kube-Proxy Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target
[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/proxy
ExecStart=/usr/local/bin/kube-proxy \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBE_MASTER \
$KUBE_PROXY_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

/etc/kubernetes/proxy文件：

###
# kubernetes proxy config
# default config should be adequate
# Add your own!
KUBE_PROXY_ARGS="--bind-address=192.168.99.102 --hostname-override=192.168.99.102 --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig --cluster-cidr=10.254.0.0/16"

启动kube-proxy:

systemctl daemon-reload
systemctl enable kube-proxy
systemctl start kube-proxy
systemctl status kube-proxy

支持集群的基本功能已经有了，可以建一个部署一个nginx应用试一下看一下。

安装kubedns插件

kubedns 为我们提供了服务发现的功能。

yaml文件通过这里下载：

https://github.com/silenceper/k8s-install/tree/master/kube-dns

在master上执行：

kubectl create -f .

至此，k8s就搭建完成了！

参考资料：

https://jimmysong.io/kubernetes-handbook/practice/install-kubernetes-on-centos.html

聊聊连接池

Sun, 20 Nov 2016 02:40:59 +0800

以下主要使用Golang作为编程语言

为什么需要连接池

我觉得使用连接池最大的一个好处就是减少连接的创建和关闭，增加系统负载能力，之前就有遇到一个问题：TCP TIME_WAIT连接数过多导致服务不可用，因为未开启数据库连接池，再加上mysql并发较大，导致需要频繁的创建链接，最终产生了上万的TIME_WAIT的tcp链接，影响了系统性能。

链接池中的的功能主要是管理一堆的链接，包括创建和关闭，所以自己在fatih/pool基础上，改造了一下：https://github.com/silenceper/pool ，使得更加通用一些，增加的一些功能点如下：

连接对象不单单是net.Conn,变为了interface{}（池中存储自己想要的格式）
增加了链接的最大空闲时间（保证了当连接空闲太久，链接失效的问题）

主要是用到了channel来管理连接，并且能够很好的利用管道的顺序性，当需要使用的时候Get一个连接，使用完毕之后Put放回channel中。

连接失效问题

使用连接池之后就不再是短连接，而是长连接了，就引发了一些问题：

1、长时间空闲，连接断开？

因为网络环境是复杂的，中间可能因为防火墙等原因，导致长时间空闲的连接会断开，所以可以通过两个方法来解决：

客户端增加心跳，定时的给服务端发送请求
给连接池中的连接增加最大空闲时间，超时的连接不再使用

在https://github.com/silenceper/pool就增加了一个这样最大空闲时间的参数，在连接创建或者连接被重新返回连接池中时重置，给每个连接都增加了一个连接的创建时间，在取出的时候对时间进行比较：https://github.com/silenceper/pool/blob/master/channel.go#L85

2、当服务端重启之后，连接失效？

远程服务端很有可能重启，那么之前创建的链接就失效了。客户端在使用的时候就需要判断这些失效的连接并丢弃，在database/sql中就判断了这些失效的连接，使用这种错误表示var ErrBadConn = errors.New("driver: bad connection")

另外值得一提的就是在database/sql对这种ErrBadConn错误进行了重试，默认重试次数是两次，所以能够保证即便是链接失效或者断开了，本次的请求能够正常响应（继续往下看就是分析了）。

连接失效的特征

对连接进行read读操作时，返回EOF错误
对连接进行write操作时，返回write tcp 127.0.0.1:52089->127.0.0.1:8002: write: broken pipe错误

database/sql 中的连接池

在database/sql中使用连接连接池很简单，主要涉及下面这些配置：

 db.SetMaxIdleConns(10) //连接池中最大空闲连接数
 db.SetMaxOpenConns(20) //打开的最大连接数
 db.SetConnMaxLifetime(300*time.Second)//连接的最大空闲时间(可选)

注：如果MaxIdleConns大于0并且MaxOpenConns小于MaxIdleConns ,那么会将MaxIdleConns置为MaxOpenConns

来看下db这个结构，以及字段相关说明：

type DB struct {
 //具体的数据库实现的interface{},
 //例如https://github.com/go-sql-driver/mysql 就注册并并实现了driver.Open方法，主要是在里面实现了一些鉴权的操作
 driver driver.Driver
 //dsn连接
 dsn string
 //在prepared statement中用到
 numClosed uint64

 mu sync.Mutex // protects following fields
 //可使用的空闲的链接
 freeConn []*driverConn
 //用来传递连接请求的管道
 connRequests []chan connRequest
 //当前打开的连接数
 numOpen int
 //当需要创建新的链接的时候，往这个管道中发送一个struct数据，
 //因为在Open数据库的就启用了一个goroutine执行connectionOpener方法读取管道中的数据
 openerCh chan struct{}
 //数据库是否已经被关闭
 closed bool
 //用来保证锁被正确的关闭
 dep map[finalCloser]depSet
 //stacktrace of last conn's put; debug only
 lastPut map[*driverConn]string
 //最大空闲连接
 maxIdle int
 //最大打开的连接
 maxOpen int
 //连接的最大空闲时间
 maxLifetime time.Duration
 //定时清理空闲连接的管道
 cleanerCh chan struct{}
}

看一个查询数据库的例子：

 rows, err := db.Query("select * from table1")

在调用db.Query方法如下：

func (db *DB) Query(query string, args ...interface{}) (*Rows, error) {
 var rows *Rows
 var err error
 //这里就做了对失效的链接的重试操作
 for i := 0; i < maxBadConnRetries; i++ {
 rows, err = db.query(query, args, cachedOrNewConn)
 if err != driver.ErrBadConn {
 break
 }
 }
 if err == driver.ErrBadConn {
 return db.query(query, args, alwaysNewConn)
 }
 return rows, err
}

在什么情况下会返回，可以从这里看到： readPack，writePack

继续跟进去就到了

func (db *DB) conn(strategy connReuseStrategy) (*driverConn, error) {

方法主要是创建tcp连接，并判断了连接的生存时间lifetime，以及连接数的一些限制，如果超过的设定的最大打开链接数限制等待connRequest管道中有连接产生(在putConn释放链接的时候就会往这个管道中写入数据)

何时释放链接?

当我们调用rows.Close()的时候，就会把当前正在使用的链接重新放回freeConn或者写入到db.connRequests管道中

 //putConnDBLocked 方法

 //如果有db.connRequests有在等待连接的话，就把当前连接给它用
 if c := len(db.connRequests); c > 0 {
 req := db.connRequests[0]
 // This copy is O(n) but in practice faster than a linked list.
 // TODO: consider compacting it down less often and
 // moving the base instead?
 copy(db.connRequests, db.connRequests[1:])
 db.connRequests = db.connRequests[:c-1]
 if err == nil {
 dc.inUse = true
 }
 req <- connRequest{
 conn: dc,
 err: err,
 }
 return true
 } else if err == nil && !db.closed && db.maxIdleConnsLocked() > len(db.freeConn) {
 //没人需要我这个链接，我就把他重新返回`freeConn`连接池中
 db.freeConn = append(db.freeConn, dc)
 db.startCleanerLocked()
 return true
 }

使用连接池管理Thrift链接

这里是使用连接池https://github.com/silenceper/pool，如何构建一个thrift链接

客户端创建Thrift的代码：

type Client struct {
 *user.UserClient
}


//创建Thrift客户端链接的方法
factory := func() (interface{}, error) {
 protocolFactory := thrift.NewTBinaryProtocolFactoryDefault()
 transportFactory := thrift.NewTTransportFactory()

 var transport thrift.TTransport
 var err error
 transport, err = thrift.NewTSocket(rpcConfig.Listen)
 if err != nil {
 panic(err)
 }
 transport = transportFactory.GetTransport(transport)
 //defer transport.Close()
 if err := transport.Open(); err != nil {
 panic(err)
 }
 rpcClient := user.NewUserClientFactory(transport, protocolFactory)
 //在连接池中直接放置Client对象
 return &Client{UserClient: rpcClient}, nil
}
//关闭连接的方法
close := func(v interface{}) error {
 v.(*Client).Transport.Close()
 return nil
}

//创建了一个 初始化连接是
poolConfig := &pool.PoolConfig{
 InitialCap: 10,
 MaxCap: 20,
 Factory: factory,
 Close: close,
 IdleTimeout: 300 * time.Second,
}
p, err := pool.NewChannelPool(poolConfig)
if err != nil {
 panic(err)
}

//取得链接
conn, err := p.Get()
if err != nil {
 return nil, err
}
v, ok := conn.(*Client)

...使用连接调用远程方法

//将连接重新放回连接池中
p.Put(conn)

写完，听见外面的🐓开始打鸣了。

开源项目：wechat sdk

Fri, 16 Sep 2016 15:40:59 +0800

一直很想自己用golang写个微信的sdk，目标是简单好用，所以利用闲暇时间（周末，中秋😁），就做出来。

项目地址:https://github.com/silenceper/wechat

目前实现了消息管理，微信网页授权，菜单管理，素材管理几个接口，看下他的基本使用：

以下是一个处理消息接收以及回复的例子：


//配置微信参数
config := &wechat.Config{
 AppID: "xxxx",
 AppSecret: "xxxx",
 Token: "xxxx",
 EncodingAESKey: "xxxx",
 Cache: memCache
}
wc := wechat.NewWechat(config)

// 传入request和responseWriter
server := wc.GetServer(request, responseWriter)
server.SetMessageHandler(func(msg message.MixMessage) *message.Reply {

 //回复消息：演示回复用户发送的消息
 text := message.NewText(msg.Content)
 return &message.Reply{message.MsgText, text}
})

server.Serve()
server.Send()

dcmp

Tue, 02 Aug 2016 15:40:59 +0800

Distributed Configuration Management Platform

提供了一个etcd的管理界面，可通过界面修改配置信息，借助confd可实现配置文件的同步。

GITHUB：https://github.com/silenceper/dcmp

API采用的是Gin Framework，写起api应用来非常方便，前端尝试了一下react。

传到Github一看，发现css，js的代码比golang还要多。 😢

Golang中http包默认路由匹配规则阅读笔记

Sat, 28 May 2016 18:00:59 +0800

一、执行流程

构建一个简单http server：

package main

import (
 "log"
 "net/http"
)

func main() {
 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
 w.Write([]byte("hello world"))
 })
 log.Fatal(http.ListenAndServe(":8080", nil))
}

使用http://127.0.0.1:8080/ 就可以看到输出了

通过跟踪http.go包代码，可以发现执行流程基本如下：

1.创建一个Listener监听8080端口
2.进入for循环并Accept请求，没有请求则处于阻塞状态
3.接收到请求，并创建一个conn对象，放入goroutine处理（实现高并发关键）
4.解析请求来源信息获得请求路径等重要信息
5.请求ServerHTTP方法，已经通过上一步获得了ResponseWriter和Request对象

func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) {
 //此handler即为http.ListenAndServe 中的第二个参数
 handler := sh.srv.Handler
 if handler == nil {
 //如果handler为空则使用内部的DefaultServeMux 进行处理
 handler = DefaultServeMux
 }
 if req.RequestURI == "*" && req.Method == "OPTIONS" {
 handler = globalOptionsHandler{}
 }
 //这里就开始处理http请求
 //如果需要使用自定义的mux，就需要实现ServeHTTP方法，即实现Handler接口。
 handler.ServeHTTP(rw, req)
}

6.进入DefaultServeMux中的逻辑就是根据请求path在map中匹配查找handler，并交由handler处理

http请求处理流程更多信息可以参考《Go Web 编程》3.3 Go如何使得Web工作

二、DefaultServeMux 路由匹配规则

先看几个路由规则：

package main

import (
 "log"
 "net/http"
)

func main() {
 //规则1
 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
 w.Write([]byte("hello world"))
 })

 //规则2
 http.HandleFunc("/path/", func(w http.ResponseWriter, r *http.Request) {
 w.Write([]byte("pattern path: /path/ "))
 })

 //规则3
 http.HandleFunc("/path/subpath", func(w http.ResponseWriter, r *http.Request) {
 w.Write([]byte("pattern path: /path/subpath"))
 })

 log.Fatal(http.ListenAndServe(":8080", nil))
}

情景一：

访问：http://127.0.0.1:8080/

返回：hello world

情景二：

访问：http://127.0.0.1:8080/path

返回：pattern path: /path/

情景三：

访问：http://127.0.0.1:8080/path/subpath/

返回：pattern path: /path/

情景四：

访问：http://127.0.0.1:8080/hahaha/

返回：hello world

先说明一些规则吧，再看代码是怎么实现的：

1.如果匹配路径中后带有/，则会自动增加一个匹配规则不带/后缀的，并跳转转到path/,解释了情景二的场景，为什么匹配到的/path/

2.我设置了这么多规则为什么规则一可以通用匹配未设置的路由信息，而且又不影响已经存在路由，内部是怎么实现的？

2.1 添加路由规则

先看两个struct，这是存放默认路由规则的：

type ServeMux struct {
 mu sync.RWMutex //处理并发，增加读写锁
 m map[string]muxEntry //存放规则map，key即为设置的path
 hosts bool // whether any patterns contain hostnames（是否包含host）
}

type muxEntry struct {
 explicit bool //是否完全匹配
 h Handler//相应匹配规则的handler
 pattern string//匹配路径
}

通过跟踪http.HandleFunc定位到如下代码，正是往上面两个struct中增加规则：

func (mux *ServeMux) Handle(pattern string, handler Handler) {
 mux.mu.Lock()
 defer mux.mu.Unlock()

 if pattern == "" {
 panic("http: invalid pattern " + pattern)
 }
 if handler == nil {
 panic("http: nil handler")
 }
 //如果已经匹配到了则panic
 if mux.m[pattern].explicit {
 panic("http: multiple registrations for " + pattern)
 }

 //增加一个新的匹配规则
 mux.m[pattern] = muxEntry{explicit: true, h: handler, pattern: pattern}

 //根据path的第一个字母判断是否有host
 if pattern[0] != '/' {
 mux.hosts = true
 }

 //！！这里看清楚 就是实现了情景二的情况 ，看判断条件
 n := len(pattern)
 if n > 0 && pattern[n-1] == '/' && !mux.m[pattern[0:n-1]].explicit{
 // If pattern contains a host name, strip it and use remaining
 // path for redirect.
 path := pattern
 if pattern[0] != '/' {
 // In pattern, at least the last character is a '/', so
 // strings.Index can't be -1.
 path = pattern[strings.Index(pattern, "/"):]
 }
 url := &url.URL{Path: path}
 mux.m[pattern[0:n-1]] = muxEntry{h: RedirectHandler(url.String(), StatusMovedPermanently), pattern: pattern}
 }
}

上面有个Helpful behavior的注释行为，就是实现了情景二的情况，他是判断如果匹配的路径中最后含有/，并且之前也不存在添加去除反斜杠的规则的话，就自动给他增加一个301的跳转指向/path/

2.2 查找路由规则

路由规则的查找就是从ServeMux 中的map去匹配查找的,的到这个handler并执行，只是会有一些处理机制，比如怎么样确保访问/path/subpath的时候是先匹配/path/subpath而不是匹配/path/呢？

当一个请求过来的时候，跟踪到了mux.match方法：

过程mux.ServerHTTP->mux.Handler->mux.handler->mux.match

func (mux *ServeMux) match(path string) (h Handler, pattern string) {
 var n = 0
 for k, v := range mux.m {
 if !pathMatch(k, path) {
 continue
 }
 //如果匹配到了一个规则，并没有马上返回handler，而且继续匹配并且判断path的长度是否是最长的，这是关键！！！
 if h == nil || len(k) > n {
 n = len(k)
 h = v.h
 pattern = v.pattern
 }
 }
 return
}

1.这里就解释了为什么设置的精确的path是最优匹配到的，因为它是根据path的长度判断。当然也就解释了为什么/可以匹配所有（看pathMatch函数就知道了，/是匹配所有的，只是这是最后才被匹配成功）

2.得到了处理请求的handler，再调用h.ServeHTTP(w, r)，去执行相应的handler方法。

等一下，handler中哪里有ServeHTTP这个方法？？

因为在调用 http.HandleFunc的时候已经将自定义的handler处理函数，强制转为HandlerFunc类型的，就拥有了ServeHTTP方法：

type HandlerFunc func(ResponseWriter, *Request)

// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
 f(w, r)
}

f(w,r)就实现了handler的执行。

脑子里面清楚，但真到表述的时候，呵呵，当做笔记啦。。。

tcp time_wait问题

Sun, 03 Jan 2016 15:40:59 +0800

问题出现：

在元旦前夕，自己维护的一个服务突然在高峰时期收到大量报警，赶紧登上服务器看一下：

最开始的反应是memcache tcp read time out ,因为之前也出现过类似的警告所以开始尝试切换memcache，但是运维反馈已经切换了好几台还是不起作用。

又看到有mysql 连接不上报错，怀疑机房内网有问题，然后有开始切换机房加机器，当时问题还是没有得到解决，这下真晕了。。。。完全排查不出什么问题（因为是高峰时期，tcp连接数自然很高，没有在意是这个问题，自己预估不够）

后来反应过来看到有好几个接口请求数增加，因为发版本的原因，是新版本才会请求这些接口，所以我暂时屏蔽了这几个口接口问题得到遏制（幸好是用户感知不到的接口）。

排查：

这个问题围绕我好几天，我屏蔽的那几个接口，反复看了好几遍，而且又将其中的sql查询分析，并没有慢请求。。。这下又彻底懵了，没有头绪。

说来也巧，高峰时期我用netstat -an 命令查看了一些，看到大量tcp time_wait 的连接，赶紧Google了下，tcp time_wait状态是在主动关闭连接的一方保持的一个状态（一般指客户端），

总共的连接数在近3w(ss -s可查)，其中有2w多都是这种连接，而且都是mysql 连接（这里边服务器程序就相当于客户端去连接mysql服务器），到这里心里大致有底了，把数据库连接池加上就好了，Golang提供了两个函数可进行配置：

SetMaxOpenConns用于设置最大打开的连接数，默认值为0表示不限制。
SetMaxIdleConns用于设置闲置的连接数。

为什么会有TIME_WAIT状态？

源于tcp链接关闭中的四次挥手，是主动关闭链接的一方产生的状态： TCP状态转化图三次握手/四次挥手：

四次挥手的过程如下：

主动关闭连接的一方，调用close()；协议层发送FIN包
被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方等待被动关闭一方的应用程序，调用close操作
被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态；
主动关闭的一方收到FIN包，协议层回复ACK；此时，主动关闭连接的一方，进入TIME_WAIT状态；而被动关闭的一方，进入CLOSED状态
等待2MSL时间，主动关闭的一方，结束TIME_WAIT，进入CLOSED状态

所以time_wait属于tcp正常的一个状态，是为了解决网络的丢包和网络不稳定锁存在的一个状态。

因为当前服务器并发相对较大，所以存在了大量的链接为关闭，如果只是几百的话，也不会影响服务器性能。

使用连接池保存长链接，可使得链接复用，不会出现大量的这种状态。

反思：

问题终于找到解决，但是回过头来想了一下，其实一开始就可以定位到的，只是很多问题集中在一起出现反而让自己不知所措，这个时候如果是敏感的人的话应该马上能够从tcp状态上看出问题，之后线上遇到问题，重要的是先解决（不管通过什么方式），之后再一步步排查。