提案征集至：2023年中国 KubeCon + CloudNativeCon 或 开源峰会

提交您的演讲至 KUBECON + CLOUDNATIVECON 或 OPEN SOURCE SUMMIT

KubeCon + CloudNativeCon 将于 2023 年 9 月 25 日至 27 日聚集来自领先的开源和云原生社区的采用者和技术专家。加入我们目前的毕业、孵化和沙盒项目，共同促进云原生计算的教育和进步。

开源峰会是开源开发人员、技术专家和社区领袖的主要活动，旨在合作、共享信息、解决问题、获取知识，推进开源创新，确保可持续的开源生态系统。这是开源代码和社区贡献者的聚集地。

如有 CFP 过程中的任何问题，请发送电子邮件至 cfp@cncf.io。

提交内容必须为英文，但如果您的提交内容被接受，您可以用英语或中文进行演示。

提交提案^[1]

值得记住的日期

• CFP 截止日期：中国标准时间 6 月 18 日晚上 11:59（UTC +8）
• CFP 通知：7 月 31 日星期一
• 日程公告：8 月 2 日星期三
• 幻灯片上传截止日期至 Sched.com：9 月 20 日星期三
• 活动日期：9 月 25 日至 27 日

KUBECON + CLOUDNATIVECON 的建议话题

• 云原生新手 – 这个内容适合那些刚接触云原生并且处于早期职业阶段的人（包括学生）。通过介绍性的演示，覆盖多个领域的基础概念。参与者可以学习云原生网络的核心概念、管理容器工作负载的存储、云原生体系结构的初始安全活动、开发云原生应用程序、如何开始参与云原生社区等方面的知识，以及更多内容。
• SDLC(软件开发生命周期) – 适合应用程序开发、持续集成和持续部署方面的内容。包括最佳实践、技术和工具等内容，例如 CI/CD 流水线和集成、容器构建、打包，以及交付云原生应用程序到部署环境等。参与者可以学习云原生独特的 SDLC 元素，同时平衡与现有软件开发方法论的集成。
• 平台工程 – 这些内容涵盖使用云原生项目构建平台、定制和扩展云原生项目、自动化基础设施运营、提高自助工具链和云原生开发者工作流程的速度等方面。参与者可以学习开发者平台和集成，以改善云原生开发体验。平台工程旨在专注于支持 SDLC 的基础组件。
• 运维+性能 – 涵盖操作云原生项目和技术、提高云原生架构的性能和可靠性，以及解决运行时或“第二天”挑战和学习的主题。这个会议对于负责管理、维护和操作云原生技术的与会者特别感兴趣，尤其是管理员、SRE 和 DevOps 人员。与会者可以在自动缩放、高可用性、性能优化、操作者和云原生集群的可靠性等领域建立专业知识。
• 安全性 – 内容涵盖云原生的安全特定方面，从检测到威胁建模、安全教育、身份和凭证管理、多租户、机密计算、云原生漏洞管理以及其他主题。参加这些演示的与会者可以期望学习有关自动缩放、提高集群可靠性的技术、性能和计算利用率优化、调试策略、高可用性、操作员以及其他在云原生环境中担任管理员或 SRE 角色的个人常遇到的主题和内容。
• 数据+处理+存储 – 这部分内容涵盖在云原生环境下管理数据模型和数据流、在云原生工作负载或基础设施中使用机器学习的新颖方法，以及存储功能、技术和挑战。与会者可以期望学习容器化数据库的使用、云原生架构中的 MLOps 和 AIOps、卷配置、存储系统的可用性和可伸缩性、Kubernetes 中的 GPU 利用率等内容。
• 网络+边缘+电信 – 涵盖了云原生环境下的网络，包括负载均衡、服务发现、网络安全和网络自动化等主题。本轨道还涵盖了云原生技术的边缘计算和电信用例，包括云原生网络功能和虚拟网络功能。参会者可以期望学习最新的网络技术和趋势，以及部署和管理云原生网络基础设施的最佳实践。第四层/第七层服务网格应该提交到服务网格轨道。
• 服务网格 – 涵盖了服务网格技术以及在云原生环境中部署和管理服务网格的最佳实践。本轨道涵盖了微服务架构中的 OSI 第 4/7 层服务网格。参会者可以期望学习服务网格的优势和挑战，如何部署和配置服务网格，以及在生产环境中管理服务网格的最佳实践。
• 可观测性 – 本内容涵盖仪表可视化、收集、处理、存储、查询、整理以及相关工作负载的指标、日志/事件、跟踪跨度和一般观测性能的方法和项目。参加这些演示的与会者可以期望学习有意义的警报、查询和操作仪表板的良好实践、面向观测性能挑战的工具和互操作性，以及如何管理警报规则定义、阈值和策略。
• 新兴和先进技术 – 包括云原生科研学术、新兴技术、面向专业工作负载的高性能计算，以及高度先进的云原生计算概念。云原生科研学术论文、早期阶段的技术概念、概念验证项目、研究计算的进展，以及高度专业的先进的或特定领域的主题，都欢迎在此专题中展示。对云原生技术的最新进展感兴趣的与会者(包括在云原生基础设施上支持科研学术工作负载的基本需求、部署和管理计算密集型工作负载、以及与云原生相关的高级或深度技术内容)，可能会被吸引到这个专题。
• 云原生体验 – 内容涉及云原生体验的所有方面，包括建立和支持云原生社区、CNCF 技术的商业价值、闪电演讲以及公开分享我们的云原生不幸经历。与会者可以获得有关建立社区、CNCF 技术的价值的一系列见解和知识，并从社区分享的不幸经历中获得启示。

开源峰会的建议话题

• 云（混合云+多云）
• 网络和边缘计算
• 开放 AI 和数据（AIGC，AI 基础设施，基础模型）
• 开放元宇宙（Web3 / Metaverse）
• FinOps
• 操作系统
• 数据库
• 编程语言和工具链（包括 Rust）
• 社区，OSPO，开放治理
• 供应链安全
• 开放硬件
• Web Assembly

提交类型

• 单人演讲：30 分钟，1 名演讲者就一个主题发表演讲。
• 双人演讲：30 分钟，2 名演讲者就一个主题发表演讲。
• 小组讨论：30 分钟，3 至 5 名演讲者之间的讨论。
• 教程：90 分钟，深入的、动手的演示，1 至 5 名演讲者。

重要提示

• 所有演讲者都必须遵守我们的行为准则^[2]。我们强烈建议演讲者参加我们的在线包容性演讲者导向课程^[3]。
• 提交的小组讨论必须包括所有参与者的姓名，以便考虑。为了促进演讲者多样性，CNCF 不接受所有男性小组讨论的提交，并且演讲者不能全部来自同一家公司。
• 演讲者将获得一张免费的活动通行证，每个被接受的演讲者将获得一张。
• 在准备您的提案时，请避免销售或营销推销，并避免讨论未经许可或可能是闭源技术；这些演讲几乎总是被拒绝，因为它们会损害我们活动的完整性，并且很少受到会议参与者的好评。
• CNCF 不会选择在过去一年内已经在以前的 Linux 基金会活动中展示过的提交。如果您的提交类似于以前的演讲，请解释这个版本的不同之处。
• 您可以在 CFP 中列出最多两个提案的演讲者，无论格式如何。如果您列在两个以上，我们将联系您从任何其他提案中删除自己。
• 您每个活动只能被选为一个小组讨论和一个非小组讨论的演讲者。
• 所有被接受的演讲者都必须在活动前提交他们的幻灯片。

准备提交您的提案

虽然我们并不打算为您提供严格的提交指南，但我们希望您能花一点时间查看以下准则，以帮助您准备最佳的提交。在开始之前，以下是您提交提案前应考虑的三件事：

• 您希望从您的演讲中获得什么？
• 您期望观众从您的演讲中获得什么？
• 您的演讲将如何帮助改善生态系统？

有很多方法可以介绍项目和技术，而不必专注于公司特定的努力。在撰写您的提案时，请记住我们上面提到的考虑事项，并想出让参与者感兴趣的方式，同时仍然让您分享经验，教育社区有关问题，或引起对项目的兴趣。

撰写您的提案

您的演讲标题将是参会者决定是否参加您的演讲的主要参考点，因此请谨慎选择。标题应准确反映您的演讲内容，并符合 Linux 基金会的包容性语言倡议^[4]。在输入标题时，请使用标题大小写^[5]。

在会议描述中，充分利用机会向程序委员会推销您的演讲，强调其问题、贡献和相关性。不要忘记技术细节，但要牢记大局。您的提案描述应聚焦、详细，并符合 Linux 基金会的包容性语言倡议^[6]。如果被接受，它将出现在网站日程表上，因此请确保它没有错误，使用完整的句子，并以第三人称书写。这个描述可以决定参会者是否参加您的演讲，因此请提供足够的信息来帮助他们做出选择，并简明扼要。演讲时间的竞争非常激烈，因此一个精心制作、引人入胜的摘要将提高您被接受的机会。

利用这个机会详细阐述您的演讲为什么重要，以及为什么参会者应该关注。解释您的内容如何有益于生态系统，或与联合主席和程序委员会分享任何其他相关信息。我们知道这可能是一个具有挑战性的问题，但像摘要一样，您的演讲的相关性至关重要，它与内容一样重要，决定是否被接受。

请说明您的提交是否是一个案例研究。换句话说，您的提交是否是一个组织实施某些东西（如实践、产品

如果您在过去一年内在 CNCF 或 Linux Foundation 的活动中展示过这个演讲，请解释该演示与您在会议描述中提出的演示之间的重大差异。

请列出所有 CNCF 托管的毕业、孵化^[7]或沙盒^[8]软件，以及您的演示如适用所关注的所有开源项目。

由于程序委员会审核了众多的提案，额外的资源可以帮助评估演讲者的熟练程度和演讲技巧。请提供您之前发表的演讲的视频或音频记录。如果您没有任何先前的演讲记录，您可以创建一个短的 YouTube 视频，让自己讲几分钟。

如何做出精彩演讲

我们希望确保提交者获得资源，以帮助他们组织出色的提交，并在被接受后，做出最好的演示。为了帮助实现这一点，我们建议观看经验丰富的演讲者 Dawn Foster 的深入讲座：克服自我怀疑，成为一名会议演讲者 – Dawn Foster，VMware^[9]。

有更多问题吗？第一次提交？不要感到害怕

CNCF 活动是了解社区和分享您的想法和工作的绝佳方式，我们强烈鼓励首次演讲者提交演讲稿。如果您对摘要不确定，请与我们联系^[10]，我们将非常乐意与您合作完善您的提案。

如何提交

第一次使用 SESSIONIZE 吗？

Sessionize 是一款基于云的活动内容管理软件，旨在直观易用。如果您需要指导，请查看如何提交您的演讲议题^[11]以获取逐步说明和有用的屏幕截图。

代表别人提交？

虽然演讲者通常会自己提交他们的会议，但他们也常常让其他人代表他们提交。提交者可以选择以其他人的名义提交^[12]，并填写必要的演讲者信息，但会议提交流程与演讲者自己提交时完全相同。

示例提交

示例标题

OCI、CRI、??: 在 Kubernetes 中理解容器运行时景观

示例描述

您可能已经听说过 OCI——这是一项标准化努力，旨在共享容器运行时、镜像和镜像分发的通用定义。再加上 Kubernetes 中的 CRI（容器运行时接口）——旨在将容器运行时从 kubelet 中抽象出来——您可能会开始想知道所有这些标准和接口在 Kubernetes 世界中对您意味着什么。从今年开始，包括 CNCF 项目 containerd 和 cri-o 在内的长列表的运行时都实现了 CRI。但您知道还有很多其他的吗？独特的 CRI 组合数量正在增长，所有这些组合都使用通用的 OCI 定义来实现运行时和镜像互操作性。但是，您如何决定哪个容器运行时适合您？显然，每个容器运行时都有权衡。本次演讲将帮助描述当前的情况，并为您提供有关每个 CRI 实现的原因和方法的详细信息。

生态系统的示例好处

在 CNCF 生态系统中，有一个反复出现的评论是容器运行时的选择数量令人困惑，特别是对于那些对我们的生态系统较新的人来说。即使是那些听过 Docker、containerd、cri-o 等名称的人，他们也很好奇为什么有许多不同的运行时可用于实现 Kubernetes 的 CRI 接口，以及是什么历史使我们达到了这一点。这个演讲有助于澄清容器运行时的景观，特别是展示了在额外的隔离技术（如 gVisor、AWS Firecracker 和 Kata 容器）方面正在进行的有趣工作，以及为什么这可能对某些安全或工作负载限制具有价值。最终，特别是我们有两个主要运行时作为 CNCF 项目，这个演讲希望为从业者、开发人员和运营商带来一定程度的洞察，了解为什么集群可能会选择不同的运行时，以及 Kubernetes 中的新功能（如 RuntimeClass）如何使支持支持具有不同隔离特性或要求的工作负载的混合集群变得更加容易。

行为准则

CNCF 及其项目社区致力于为参与者提供无骚扰的体验。所有提交者都必须遵守我们的行为准则^[13]。

CFP 问题

如果您对 CFP 流程有任何疑问，请通过 cfp@cncf.io 与我们联系。

参考资料