博客指南

这些指南涵盖了 Kubernetes 主博客和 Kubernetes 贡献者博客。

所有博客内容还必须遵循内容指南中的总体政策。

准备开始

确保你熟悉为 Kubernetes 博客贡献内容的介绍部分， 不仅是为了了解两个官方博客及其之间的区别，也是为了对整个过程有一个概览。

Kubernetes 项目仅接受原创内容，且必须为英文。

这一限制甚至延伸至推广其他 Linux 基金会和 CNCF 项目。 许多 CNCF 项目都有自己的博客。对于特定项目的帖子，这些博客通常是更好的选择， 即使那个其他项目是专门为与 Kubernetes （或与 Linux 等）协同工作而设计的。

相关内容

文章必须包含适用于整个 Kubernetes 社区的内容。例如，投稿应侧重于上游 Kubernetes，而不是特定供应商的配置。 对于提交到主博客且不是镜像文章的文章， 文章中的超链接应通常指向官方 Kubernetes 文档。 在进行外部引用时，链接应该是多样的 - 例如，投稿不应只包含返回单个公司博客的链接。

官方 Kubernetes 博客不是进行供应商宣传或推广 Kubernetes 外部特定解决方案的地方。

有时，这之间的平衡很微妙。你可以在 Slack （#sig-docs-blog） 上询问某篇文章是否适合发布在 Kubernetes 博客和/或贡献者博客 - 不要犹豫，随时联系。

内容指南无条件适用于博客文章及其添加的 PR。 请记住，指南中的一些限制仅与文档相关；那些标记的限制不适用于博客文章。

本地化

网站已被本地化为多种语言；英文是所有其他本地化的“上游”。即使你懂另一种语言并愿意提供本地化， 这也应该是一个单独的 PR（参见每个 PR 的语言）。

版权和重用

你必须编写原创内容， 并且你必须拥有将该内容授权给云原生计算基金会（Cloud Native Computing Foundation） 的权限（这样 Kubernetes 项目才能合法发布它）。 这意味着不仅直接抄袭是被禁止的，如果你没有权限满足 CNCF 版权许可条件 （例如，如果你的雇主有关于知识产权的政策限制了你能做的事情）， 你也不能撰写博客文章。

license 允许将博客的内容用于商业目的，但反之则不然。

特别兴趣小组和工作组

与参与 Kubernetes SIG 活动或其成果相关的主题总是合适的 （参见贡献者通讯团队中的工作以获得这些帖子的支持）。

该项目通常会将这些文章镜像到两个博客上。

国家对内容的限制

Kubernetes 网站拥有中国政府颁发的互联网内容提供者（ICP）许可证。 Kubernetes 不能发布那些会被中国政府官方网络内容过滤系统阻止的文章 （尽管这种情况不太可能发生）。

博客特定内容指南

除了通用的风格指南外， 博客文章应该（但不是必须）遵循 博客特定风格建议。

本页面其余部分为附加指南；这些并不是文章必须遵守的严格规则，但如果文章明显不符合这里的建议， 审稿人可能会（也应该）要求对文章进行编辑。

图表和插图

对于插图 —— 包括图表或图形 —— 在可行的情况下，使用图形简码。 你应该设置一个alt属性以提高可访问性。

使用矢量图像进行插图、技术图表和类似图形；强烈建议使用 SVG 格式。

使用光栅图像进行插图的文章更难以维护，在某些情况下， 博客团队可能会要求作者在文章可以发布之前进行修改。

时效性

博客文章应力求面向未来：

• 鉴于项目的开发速度，SIG Docs 倾向于 timeless 写作：即不需要更新就能保持准确的内容。
• 相较于撰写高层次概述的博客文章，添加教程或更新官方文档可能是更好的选择。
• 考虑将长技术内容集中在博客文章的呼吁行动中，并关注问题空间或为什么读者应该关心。

内容示例

以下是一些适合 主 Kubernetes 博客的内容示例：

• 关于 Kubernetes 新功能的公告
• 解释如何使用 Kubernetes 实现某个目标；例如，告诉我们你在基本滚动更新想法上的低操作改进
• 比较几个与 Kubernetes 和云原生有关的不同软件选项。可以提及其中一个选项的链接，但必须充分披露你的利益冲突/关系。
• 讲述问题或事件的故事，以及你是如何解决它们的
• 讨论构建针对特定用例的云原生平台的文章
• 你对 Kubernetes 的优缺点的看法

• 关于非核心 Kubernetes 的公告和故事，例如 Gateway API
• 发布后公告和更新
• 关于重要的 Kubernetes 安全漏洞的消息
• Kubernetes 项目更新
• 教程和操作指南
• 围绕 Kubernetes 和云原生的思想领导力
• Kubernetes 的组件是故意设计成模块化的，因此撰写关于现有集成点的文章 （如 CNI 和 CSI）是相关的。只要你不是在写供应商宣传，你也可以写这些集成的另一端是什么。

这里有一些适合 Kubernetes 贡献者博客的内容示例：

• 关于如何测试你对 Kubernetes 代码的更改的文章
• 围绕非代码贡献的内容
• 讨论设计仍在讨论中的 alpha 特性的文章
• “认识团队”文章，介绍工作组、特别兴趣小组等
• 关于如何编写将成为 Kubernetes 一部分的安全代码的指南
• 关于维护者峰会及其成果的文章

不会被接受的内容示例

然而，项目不会发布：

• 供应商宣传
• 你在其他地方已发布过的文章，即使是发布在你自己的低流量博客上
• 仅有少量解释的大段示例源代码
• 关于外部项目的更新，如果该项目依赖于 Kubernetes（请将这些内容发布在外项目自己的博客上）
• 关于与特定云提供商一起使用 Kubernetes 的文章
• 批评特定人士、人群或企业的文章
• 包含重要技术错误或误导性细节的文章（例如： 如果你建议在生产集群中关闭一个重要安全控制，因为其可能带来不便， Kubernetes 项目可能会拒绝该文章）