2021年中国 KubeCon + CloudNativeCon + Open Source Summit - 线上峰会

在现实世界中开发机器人应用程序具有挑战性。开发人员必须处理各种各样的传感器和硬件，每个传感器和硬件都有独特的软件开发工具包 (SDK)、数据格式，并在不同的软件环境中运行，这使得机器人系统很脆弱，随时可能出现故障。那是机器人操作系统出现之前的黑暗时代。机器人操作系统统一了编程接口和通信机制，为机器人应用开发人员带来了曙光。而我们相信云原生会使这种曙光更光明。通过容器和 Kubernetes 系统，开发人员可以启动大量资源并行进行机器人仿真，并有效地管理机器人应用程序的整个生命周期。在本次演讲中，演讲者将介绍“云原生之前”的机器人开发情况，以及云原生如何让机器人开发人员的生活更轻松。内容包括：——将机器人应用程序移植到容器中——用 Kubernetes 系统在云端进行多个机器人模拟——在真正的机器人上部署和管理应用程序 -——机器人编队操作，远程操作

Developing a robot application in the real world is challenging. Developers have to handle heterogeneous sensors and hardware, each with unique SDK, data format and runs in different software environments, making robot system fragile, ready to fail. That is the dark age before ROS. ROS unifies the programming interface and communication mechanism and brings the first light to robot application developers. While we believe cloud native will make the light brighter. With containers and Kubernetes, developers can launch massive resources to do robot simulation in parallel and efficiently manage the whole life cycle of robot application. In this talk, speakers will introduce the "pre cloud native" robot development situation and how cloud native makes robot developers' life easier. The content includes: - Porting robot application to containers - Multiple robot simulations on the cloud with Kubernetes - Deploying and managing the application on a real robot - Robot Fleet Ops, Tele Ops

现实世界中的恶意攻击者如何攻击 K8s 群集？如何防止容器逃逸？如何防止黑客绕过普通旧数据安全策略？如何防止黑客侧向移动？本次演讲将回答上述问题。开发人员和集群管理员可以学习如何构建一个安全的、多租户的、大规模的 Kubernetes 集群，并根据本讲座保护集群中的容器和数据。在过去的几年中，这位演讲者在 Blackhat、Hack In the Box、CIS 和 WHT 等会议上分享了黑客如何攻击 Kubernetes 和 Service Mesh 等基础设施。“研究攻击技术”的目的是为了防御，本课题将分享腾讯在多租户 Kubernetes 集群安全建设方面的经验和思路，并使用 read-world 攻击案例展示安全风险并提出解决方案。

How do real-world malicious attackers attack the K8s cluster? How to prevent container-escape? How to prevent hackers from bypassing Pod Security Policy? How to prevent hackers from lateral movement? This talk will answer the questions above. Developers and cluster administrators can learn how to build a secure, multi-tenant, large-scale Kubernetes cluster, and protect the containers and data in the cluster based on this talk. In the past few years, the speaker have shared how hackers attacked infrastructure such as Kubernetes and Service Mesh at conferences such as Blackhat, Hack In The Box, CIS, and WHT and so on. The purpose of "researching attack techniques" is for defend, this topic will share Tencent's experience and thoughts on security construction in multi-tenant Kubernetes clusters, and use read-world attack cases to show security risks and propose solutions.

现如今，Kubernetes 在企业中的运用越来越普遍，其各种不完善之处也在逐步得到改善，优雅的节点关闭就是其中之一。Kubernetes 1.19 版开始为优雅的节点关闭提供支持。社区已经做了很多努力来确保实现这一功能。一个长期赞赏 Kubernetes 的初学者，从熟悉社区开发环境开始并参与其中，一步步熟悉 Kubernetes，然后参与开发了一个小功能——基于 Pod 优先级的优雅的节点关闭，本次分享的内容如下：为什么我们需要优雅的节点关闭？参与了基于 Pod 优先级的优雅的节点关闭的开发；逐渐了解 Kubernetes 社区的发展与合作。

At present, the use of Kubernetes in enterprises is becoming more and more popular, and its various imperfections have also been improved little by little, and graceful node shutdown is one of them. Kubernetes 1.19 version started to provide support for graceful node shutdown. The community has made many efforts to ensure this feature. A beginner who has been admiring Kubernetes for a long time starts with familiarity with the community development environment and participates in it, familiarizes with Kubernetes step by step, and then participates in the development of a small feature-graceful node shutdown based on Pod priority The content of this sharing is as follows: Why do we need graceful node shutdown Participated in the development of graceful node shutdown based on Pod priority Gradually understand Kubernetes community development and collaboration

跨多个版本升级 Kuberentes 的风险更大。许多客户选择使用集群迁移（即创建一个新的高版本集群，然后将应用程序从低版本集群迁移到高版本集群）而不是升级集群。然而，如何在零停机的情况下迁移集群已经成为一个重大挑战。这项建议提出了解决问题的办法。

Upgrading Kuberentes across multiple versions is more risky. Many customers choose to use cluster migration (that is, create a new high-version cluster, and then migrate the applications from the low-version cluster to the high-version cluster) instead of upgrading the cluster. However, how to migrate cluster with zero downtime has become a major challenge. This proposal propose a way to solve the problem.

Bagua 是快手科技和苏黎世理工 (ETH Zürich) 共同开发的一个项目，在 Kubernetes 上支持高性能分布式深度学习，而无需特殊的网络设备和严格的调度。得益于 Bagua 创新的通信算法和与 Kubernetes 的集成，用户可以在 Kubernetes 集群上通过普通以太网连接水平扩展培训，并提供出色的加速保证。Bagua 的有效性在各种场景和模型中得到了验证，包括 ImageNet 上的 ResNet、Bert Large，以及在快手的大规模工业应用，如：具有数十个 TB 参数的推荐模型训练，超过 10 亿张图像/视频的视频/图像理解，具有 TB 级别数据集的 ASR 等。在端到端性能方面，在 Kubernetes 生产集群中，Bagua 在不同任务范围内的端到端训练时间显著超过 PyTorch-DDP、Horovod 和 BytePS（高达 1.95 倍）。

Bagua is a project developed by Kuaishou Technology and ETH Zürich to support high performance distributed deep learning on Kubernetes without requiring special network devices and restrictive scheduling. Benefiting from Bagua's innovative communication algorithms and integration with Kubernetes, users can scale the training horizontally with excellent speedup guarantee, on a Kubernetes cluster with just ordinary ethernet connection. Bagua's effectiveness has been validated in various scenarios and models, including ResNet on ImageNet, Bert Large, and huge scale industrial applications at Kuaishou such as ● recommendation model training with dozens of TB parameters, ● video/image understanding with >1 billion images/videos, ● ASR with TB level datasets, etc. As for end to end performance, in a production Kubernetes cluster, Bagua can outperform PyTorch-DDP, Horovod and BytePS in the end-to-end training time by a significant margin (up to 1.95×) across a diverse range of tasks.

本次演讲将讨论在 Kubernetes 这样的大型项目中跟踪依赖关系的重要性，以及“depstat”，这是一个为跟踪 Kubernetes 代码库的依赖关系更新而创建的工具。Kubernetes 存储库每天都会收到许多 pull 请求，其中许多请求会带来依赖关系的变更。大多数时候，维护人员必须手动发现这些更改，确定它们对整个依赖谱的影响，然后 ping 此 pull 请求作者以采取行动。为了避免这种情况并帮助更好地跟踪依赖项更新，创建了 depstat。Depstat 是一个上游项目，用于分析 go 模块支持的项目的依赖关系。它目前作为 Kubernetes 代码库中 prow 作业的一部分运行，并提供四个关键的依赖关系相关指标。“depstat”还提供了通过创建图形直观分析依赖关系的能力。

This talk will be about the importance of tracking dependencies in a large project like Kubernetes and about "depstat" which is a tool created to track dependency updates to the Kubernetes codebase. The Kubernetes repository receives many pull requests each day many of which bring dependency changes with them. Most of the time, the maintainers manually have to spot these changes, determine their effects on the overall dependency tree, and then ping the pull request authors to take action. To avoid this and help better track the dependency updates, depstat was created. depstat is an upstream project which analyzes dependencies for go modules enabled projects. It currently runs as part of a prow job in the Kubernetes code repository and provides four crucial dependency-related metrics. "depstat" also provides the ability to analyze dependencies visually by creating a graph.

我该使用哪种服务网格，如何开始？有哪些不同的服务网格，它们的对比情况如何？了解不同服务网格的功能性，并直观地操作网格配置。本次闪电式演讲介绍了一种开源多服务网格管理平面，Meshery，其提供（五种并且未来还会持续增长）不同的服务网格，还介绍了其示例应用程序，并对服务网格部署的性能进行基准测试。Meshery 促使对 Istio 的各种配置场景进行基准测试，比较网格内外以及不同网格之间的服务（应用程序）的性能。其根据部署最佳实践检查网格和服务配置。部分服务网格项目使用 Meshery 作为每个版本的性能基准工具。

Which service mesh should I use and how do I get started? What are the different service meshes, and how do they contrast? Learn about the functionality of different service meshes and visually manipulate mesh configuration. This lightning talk introduces Meshery, an open source, multi-service mesh management plane that provisions (five and counting) different service meshes, their sample applications and benchmarks the performance of service mesh deployments. Meshery facilitates benchmarking various configuration scenarios of Istio, comparison of performance of services (applications) on and off the mesh and across different meshes. It vets mesh and services configuration against deployment best practices. Some of the service mesh projects use Meshery as their performance benchmark tool for each release.

Vivo 是世界上最大的智能手机公司之一。人工智能实验室的数百名工程师和研究人员在 NLP、CV、推荐、演讲等各个领域工作，带来了各种各样复杂的模型训练和服务案例。人工智能计算平台的建立是为了解决两大挑战：1.为大规模分布式模型培训和服务提供有效的资源调度。2.实现计算资源的高利用率，特别是昂贵的 GPU 设备。今天，该平台有几个生产集群，数千个 GPU 节点和数百个 GPU 节点。每天会部署数百个服务，运行数百个 ML 作业。这一节将讨论如何使用 Kubernetes、kube-batch、kubeflow 和其他开源软件构建平台。它还将涵盖他们遇到的问题，来之不易的最佳实践和他们对开源社区的贡献。

Vivo is one of the biggest smartphone companies in the world. Hundreds of engineers and researchers of AI Lab are working on various areas like NLP, CV, recommendation, speech, etc., which bring various and complicated cases of model training and serving. The AI computing platform is built to address two major challenges: 1. Provide efficient scheduling of resources for massively distributed model training and serving. 2. Achieve high utilization of computing resources, especially expensive GPU devices. Today the platform has several clusters on production, thousands of GPU nodes and hundreds of GPU nodes. Hundreds of services are deployed and hundreds of ML jobs are run every day. This session will cover how the platform is built with Kubernetes, kube-batch, kubeflow, and other OSS. It will also cover the issues they ran into, the hard-earned best practices and the contribution they made to the open-source community.

许多大数据业务都在 Kubernetes 集群上运行。为了使运行在不同 Kubernetes 集群上的大数据业务能够高效地访问彼此的数据，需要一种新的方式在异构多 Kubernetes 集群之间建立高性能、简单的网络通信。在第二层网络中，我们选择主机路由进行通信，以保证网络性能。主流容器网络接口 (CNI) 支持此功能。在第三层网络中，我们选择主流容器网络接口支持的 vxlan 隧道技术连接网络。对于异构容器网络接口，在第二层网络中，它们可以直接通信。在第三层网络中，它们的 VNI 可能不同，因此无法在集群之间创建 vxlan 隧道，因此至少可以通过编程扩展一个容器网络接口以适应另一个容器网络接口，确保使用相同的 VNI 在两个容器网络接口之间建立 vxlan 隧道，我们选择 antrea 作为核心容器网络接口以支持可配置的 VNI。

Many big data business are running on Kubernetes cluster. In order to allow big data business running on different Kubernetes' clusters efficiently access each other's data, it needs a novel way to establish high peformance and simple network communitcation between heterogeneous multi Kubernetes' clusters. In the second layer network, we chose the host routing to communicate to ensure network performance. The mainstream CNI supports this function. In the third layer network, we chose the vxlan tunnel technology supported by the mainstream CNI to connect the network. For heterogeneous CNI, in the second layer network, they can communicate directly. In the third layer network, their VNI could be different that the vxlan tunnel cannot be created between the clusters, so at least one CNI can be extended by programming to adapt to another CNI, ensure that the same VNI is used to establish a vxlan tunnel between the two CNIs, we chose antrea as the core CNI to support configurable VNIs.

随着 Windows 容器的成熟，大部分 Windows 应用程序和服务正在迁移到 Kubernetes。即使拥有 Linux 工作负载管理的成功经验，大规模管理 Windows 工作负载也是一项挑战。您知道 Windows 工作负载的暂存空间吗？您是否曾经因过度配置的暂存空间而导致节点崩溃？我们如何避免孤立磁盘？它怎么可能在滚动更新时陷入困境？如何优雅地关闭守护程序？组托管服务帐户 (GMSA) 作为在 Windows 上运行任务和应用程序的更安全的方式，您知道组托管服务帐户是如何集成到 Windows 群集中的吗？你还在纠结于 Kubernetes 上的组托管服务帐户与动态目录的集成吗？

As Windows containers become mature, a large portion of Windows applications and services are moving to Kubernetes. Even with the successful experience of Linux workloads management, it is challenging to manage Windows workloads at scale. Did you know the scratch space for windows workloads? Have you ever had a node crash caused by over-provisioned scratch space? How do we avoid the orphan disks? how could it be prone to get stuck at rolling update? How gracefully shutdown Daemonset? Group Managed Service Accounts (gMSA) as a more secure way to run tasks and applications on windows, do you know how gMSA integrates into the windows clusters? Are you still struggling on gMSA integration with Active Directory on Kubernetes?

随着云本地边缘计算的实现，越来越多的边缘设备需要与.云协作。此外，随着各种专业芯片、硬件加速卡和微机器学习技术的发展，许多通用资源较低的专用设备也需要边缘云协同。因此，轻量级容器沙箱技术需要满足低服务开销、快速启动和服务隔离的要求。为了解决边缘设备的多体系结构系统迁移问题，实现统一的应用运行时，降低开发和维护成本，需要一种统一的跨体系结构运行时技术。

With the implementation of cloud-native edge computing, more and more edge devices need to collaborate with the cloud. In addition, with the development of various professional chips, hardware acceleration cards, and tinyML technologies, many dedicated devices with low general resources also require edge-cloud synergy. Therefore, lightweight container sandbox technology is required to meet the requirements of low service overhead, fast startup, and service isolation. A unified cross-architecture runtime technology is required to solve the problem of multi-architecture system migration of edge devices, achieving unified application runtime and reducing development and maintenance costs.