这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

为 Kubernetes 博客做贡献

Kubernetes 有两个官方博客，同时 CNCF 也有其自己的博客， 你也可以在 CNCF 博客上面撰写 Kubernetes 相关内容。对于 Kubernetes 主博客， 我们（Kubernetes 项目）希望发布具有不同视角和特定关注点的文章，这些文章需与 Kubernetes 有所关联。

除极少数特殊情况外，我们只发布未在其他任何地方提交过或发表过的内容。

参阅博客指南了解更多相关要求。

Kubernetes 官方博客

主博客

Kubernetes 主博客由 Kubernetes 项目组发布新特性、社区报告以及可能与 Kubernetes 社区相关的所有新闻。这些内容面向终端用户和开发者。 大部分博客的内容围绕核心项目展开，但 Kubernetes 作为一个开源项目，也鼓励大家提交关于生态系统中其他方面的内容！

任何人都可以撰写博文并提交发布。除极少数特殊情况外，我们仅发布未在其他任何地方提交过或发表过的内容。

贡献者博客

Kubernetes 贡献者博客面向的是参与 Kubernetes 的开发者， 而非使用 Kubernetes 的用户。Kubernetes 项目会有意同时在两个博客上都发布某些文章。

任何人都可以撰写博文并提交审核。

文章更新与维护

Kubernetes 项目不维护博客中较旧的文章。这意味着， 任何发布超过一年的文章通常不接受提交要求修改的 Issue 或 PR。 为了避免形成惯例，这种即使从技术角度看正确的 PR 也可能会被拒绝。

但以下情况是例外：

  • （更新）标记为 Evergreen 的文章
  • 移除或更正已被证明错误且可能导致危险操作的文章
  • 一些修复工作，确保现有文章的渲染仍然正确

对于超过一年且未标记为 Evergreen 的文章，网站会自动显示一条通知，提醒读者内容可能已经过时。

Evergreen 文章

你可以在文章的 front matter 中添加 evergreen: true 将某篇文章标记为 Evergreen（长期维护）。

只有当 Kubernetes 项目承诺长期维护某篇博文时，我们才会将其标记为长期维护 （即在 front matter 中设置 evergreen: true）。 有些博文确实值得长期维护，例如 Kubernetes 发布公告通常都会由 Release Comms Team（发布沟通团队）标记为 Evergreen。

接下来

1 - 博客指南

这些指南涵盖了 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 项目可能会拒绝该文章）

2 - 博客文章镜像

官方有两个 Kubernetes 博客，CNCF 也有自己的博客，你也可以在其中了解 Kubernetes。
对于主要的 Kubernetes 博客，我们（Kubernetes 项目）喜欢发表具有不同视角和特别焦点的文章， 这些文章与 Kubernetes 有一定的关联。

有些文章会同时出现在两个博客上：一篇文章是主要版本，另一篇是另一个博客上的镜像文章。

本文介绍了镜像的标准、镜像的动机，并解释了你应该做什么来确保文章发布到两个博客。

准备开始

请确保你已熟悉为 Kubernetes 博客贡献内容的介绍部分， 这不仅是为了了解两个官方博客及其之间的区别，还能帮助你概览整个发布流程。

为什么要镜像

镜像几乎总是从贡献者博客到主博客。项目组不仅针对有关贡献者社区或一部分文章这么做， 而且和 Kubernetes 主博客更为广泛的读者相关。

作为作者（或评审者），请考虑目标受众，并判断该博客文章是否适合发布在主博客上。
例如：如果目标受众仅限于 Kubernetes 的贡献者， 那么贡献者博客可能更为合适；
如果博客文章是关于开源的普遍话题，那么它可能更适合发布在 Kubernetes 项目之外的其他网站上。

这种对目标受众的考量同样适用于原创文章和镜像文章。

Kubernetes 项目愿意镜像任何发布在 https://kubernetes.dev/blog/ （贡献者博客）上的文章，但前提是满足以下所有条件：

  • 镜像文章的发布日期必须与原始文章相同（发布时间也应相同，但在特殊情况下，可以设置最多延迟 12 小时的时间戳）。

  • 对于在原始文章已合并到贡献者博客之后，向主博客添加镜像文章的 PR，请确保满足以下所有条件：

    • 在原始文章发布到贡献者博客之后，没有文章发布到主博客。

  • 在原始文章的发布时间和镜像文章的发布时间之间，主博客没有文章发布计划。

这是因为 Kubernetes 项目不希望在人们的订阅源（例如 RSS）中插入文章，除非是在订阅源的末尾。

  • 原始文章不违反任何强烈推荐的评审指南或社区规范。

  • 镜像文章的 canonicalUrl 将在其前言中正确设置。 canonicalUrl。

  • 原文章的读者会认为其相关

  • 文章内容与镜像文章出现的目标博客主题一致

从主博客到贡献者博客的镜像操作很少见，但理论上是可行的。

如何镜像

你需要向另一个 Git 仓库（通常是 https://github.com/kubernetes/website） 提交一个 PR，以添加该文章。此操作应在文章合并之前完成。

作为文章的作者，你应该为镜像文章设置规范 URL， 并将其指向原始文章的 URL（你可以使用预览功能预测 URL，并在实际发布前填写此内容）。 在前言中使用 canonicalUrl 字段来完成这一设置。

3 - 发布后沟通

Kubernetes 的发布沟通（Release Comms） 团队（隶属于 SIG Release） 负责管理发布相关的公告，这些公告会发布在主项目博客上。

每次发布之后，发布沟通团队会在一段时间内接管主博客，并发布一系列额外的文章， 用于解释或宣布与该版本相关的变更。这些额外的文章被称为发布后沟通（Post-release comms）。

参与发布后沟通

在一个发布周期中，作为贡献者，你可以选择参与关于 Kubernetes 即将发生的变更的发布后沟通。

要选择参与，你需要针对 k/website 提交一个草稿形式的占位拉取请求（PR）。 最初，这可以是一个空提交。在占位 PR 的描述中，请提及相关的 KEP（Kubernetes Enhancement Proposal） 问题或其他 Kubernetes 改进相关的问题。

当你提交草稿拉取请求时，需要以 main 作为基础分支， 而不是针对 dev-1.34 分支。 这与即将发布的变更和新功能的流程不同。

你还应在相关的 kubernetes/enhancements 问题下留下评论，并附上拉取请求的链接，以通知负责本次发布的发布沟通团队。 你的评论有助于团队了解该变更需要发布公告，并确认你的 SIG 已选择参与。

除此之外，理想情况下，你还应通过 Slack（频道 #release-comms） 联系发布沟通团队，告知他们你已完成上述操作并希望选择参与。

准备文章内容

你应该遵循常规的文章提交流程， 将你的占位 PR 转变为可供评审的内容。然而，对于发布后沟通， 你可能不会有一个写作伙伴；取而代之的是，发布沟通团队可能会指派一名成员来帮助指导你的工作。

你应该压缩拉取请求中的提交； 如果你不确定如何操作，完全可以向发布沟通团队或博客团队寻求帮助。

只要你的文章在前言中被标记为草稿（draft: true）， 该 PR 就可以在发布周期的任何时间合并。

发布

在实际发布之前，发布沟通团队会检查哪些内容已经准备就绪 （如果到了截止日期仍未准备好，且你没有获得豁免，那么公告将不会被收录）。 他们为即将发布的文章制定时间表，并开启新的拉取请求，将这些文章从草稿转为已发布。 以将这些文章从草稿状态变为已发布状态。

博客团队的批准者仍然需要对从草稿到可发布的内容提供最终的签字批准。 在发布日前，用于发布这些公告的拉取请求（PR）应已获得 LGTM（“我觉得不错”） 和批准标签，同时还需要添加 do-not-merge/hold 标签，以确保 PR 不会过早合并。

一旦实际发布完成并且网站 Git 仓库解冻，发布沟通团队或发布团队可以立即取消保留 PR（或一组 PR） PR（或一组 PR）的 hold 状态。

在每篇文章预定发布的当天，自动化流程将触发网站构建，该文章将会变成可见。

4 - 作为博客写作伙伴提供帮助

Kubernetes 有两个官方博客，同时 CNCF 也有自己的博客，你也可以在其中撰写与 Kubernetes 相关的内容。
阅读为 Kubernetes 博客贡献内容以了解这两个博客的详细信息。

当人们作为作者为任一博客撰稿时，Kubernetes 项目会将作者配对为写作伙伴。 本页面解释了如何履行伙伴角色。

在继续阅读本页面之前，你应该确保至少已经阅读了文章提交的概述。

伙伴职责

作为写作伙伴，你的职责包括：

  • 协助博客团队准备文章，使其达到可合并和发布的状态；
  • 支持你的伙伴创作高质量的内容，确保其适合合并；
  • 对你伙伴撰写的文章提供审阅意见。

当团队将你与另一位作者配对时，理念是你们通过互相审阅对方的草稿文章来彼此支持。 大多数阅读 Kubernetes 博客文章的读者并非专家； 内容应当尝试为这类读者群体提供易于理解的信息，或者至少适当地支持非专家读者。

博客团队也会在整个从草稿到发布的流程中帮助你们。他们可以直接批准你的文章发布， 或者安排相应的批准流程。

支持博客团队

你的主要职责是及时沟通你的工作量、可用时间以及进展情况。如果几周过去了， 你的伙伴还没有收到你的消息，这将会导致整体工作花费更多的时间。

支持你的伙伴

支持伙伴的过程分为两个部分：

（这是推荐的选项）

博客团队建议文章的主要作者通过 Google Doc 或 HackMD（由作者选择）构造协作编辑环境。 之后，主作者将该文档共享给以下人员：

  • 所有共同作者
  • 你（他们的写作伙伴）
  • 理想情况下，还应包括一位博客团队中指定的负责人。

作为写作伙伴，你需要阅读草稿内容，并直接提出建议或以其他方式提供反馈。 博客文章的作者通常也会反过来成为你的写作伙伴， 因此他们会针对你所撰写的文章草稿提供类似的反馈。

你的角色是推荐最小的修改集，以使文章适合发布。如果某个图表完全无法理解， 或者文字表达非常不清晰，请提供反馈。如果你对措辞或标点符号有轻微的不同意见， 请忽略它。只要符合博客指南， 让文章作者以他们自己的风格写作即可。

在此完成后，主作者将发起一个 PR 并使用 Markdown 提交文章。 然后你可以提供审阅意见。

一些作者更喜欢从协同编辑开始， 而另一些人则喜欢直接进入 GitHub。

无论他们选择哪种方式，你的角色是提供反馈，使博客团队能够轻松完成审核， 并确认文章可以作为草稿合并。有关作者需要完成的操作， 请参阅向 Kubernetes 博客提交文章。

使用 GitHub 的建议功能指出需要修改的地方。

一旦 Markdown 文件和其他内容（例如图片）看起来没有问题， 你就可以提供正式的审阅意见。

审阅 PR

遵循**审阅 PR **一文的博客部分所给的要求。

当你认为所发起的博客 PR 足够好可以合并时，在 PR 中添加 /lgtm 评论。

这一注释向仓库自动化工具（Prow）内容申明内容“在我看来没有问题”。 Prow 会推进相关流程。/lgtm 命令允许你将自己的意见公开出来， 无论你是否正式成为 Kubernetes 项目的一员。

你或文章作者应通知博客团队有文章已准备好进行签发。根据提交指南， 文章前面应已标记为 draft: true。

后续步骤

作为写作伙伴，没有第四步。一旦 PR 准备好合并， 博客团队（或者，对于贡献者网站，贡献者通信团队）将会接手。 根据反馈，你可能需要返回到前面的步骤，但通常你可以认为作为伙伴的工作已经完成。