灵雀云

EndpointSlices是一个令人兴奋的新API，它提供了Endpoints API的可扩大和可扩张的代替计划。EndpointSlice跟踪Pod服务前面的IP地址，端口，筹备状况和拓扑信息。在Kubernetes(https://www.alauda.cn/product/detail/id/240.html) 1.19中，默认状况下从EndpointSlices中通过kube-proxy读取启用了此性能，而非Endpoints。只管这个更改看起来不起眼，但它能够使大型群集中的可伸缩性失去显著改善。它还在未来的Kubernetes版本中启用了重要的新性能，例如拓扑路由感知。1 Eendpoints API的可扩展性限度应用Endpoints API，一个服务只有一个Endpoints资源。这意味着它须要为反对相应服务的每个Pod存储IP地址和端口（网络端点）。这导致应用微小的API资源。为了解决此问题，kube-proxy在每个节点上运行，并监督Endpoints资源的任何更新。如果在Endpoints资源中甚至只有一个网络端口产生更改，则整个对象也必须发送到每个实例的kube-proxy。Endpoints API的另一个限度是，它限度了能够为服务跟踪的网络端点的数量。存储在etcd中的对象的默认大小限度为1.5MB。在某些状况下，这可能会将Endpoints资源限度为5,000个Pod IP。对于大多数用户而言，这不是问题，然而对于服务靠近此大小的用户而言，这将成为一个重大问题。为了阐明这些问题的严重性，举一个简略的例子是有帮忙的。思考具备5,000个Pod的服务，它最终可能具备1.5MB的Endpoints资源。如果该列表中的单个网络Endpoints都产生了更改，则将须要将残缺的Endpoints资源分配给群集中的每个节点。在具备3,000个节点的大型群集中，这成为一个很大的问题。每次更新将波及跨集群发送4.5GB数据（1.5MB Endpoints * 3,000个节点）。这简直足以填满DVD，并且每次Endpoints更改都会产生这种状况。设想一下，如果滚动更新会导致全副5,000个Pod都被替换-传输的数据量超过22TB（或5,000 DVD）。2 应用EndpointSlice API拆分端点EndpointSlice API旨在通过相似于分片的办法来解决此问题。咱们没有应用单个Endpoints资源跟踪服务的所有Pod IP，而是将它们拆分为多个较小的EndpointSlice。思考一个示例，其中一个服务后端有15个Pod。咱们最终将取得一个跟踪所有端点的单个Endpoints资源。如果将EndpointSlices配置为每个存储5个端点，咱们最终将取得3个不同的端点EndpointSlices：默认状况下，EndpointSlices每个存储多达100个端点，只管能够应用kube-controller-manager上的--max-endpoints-per-slice标记进行配置。EndpointSlices将可扩展性进步了10倍。该API大大提高了网络可伸缩性。当初，当增加或删除Pod时，只需更新1个小的EndpointSlice。当单个Service有成千盈百的Pod时，这种差别变得非常明显。可能更重要的是，既然服务的所有Pod IP都不须要存储在单个资源中，那么咱们就不用放心etcd中存储的对象的大小限度。EndpointSlices已用于将服务扩大到超过100,000个网络端点。所有这些都与kube-proxy所做的一些重大性能改良联合在一起。当大规模应用EndpointSlices时，用于端点更新的数据将大大减少，并且kube-proxy应该更快地更新iptables或ipvs规定。除此之外，服务当初能够扩大到至多任何以前的限度的10倍。3 EendpointSlices启用新性能作为Kubernetes(https://www.alauda.cn/product/detail/id/240.html) v1.16中的alpha性能引入的EndpointSlices旨在在未来的Kubernetes版本中启用一些令人兴奋的新性能。这可能包含双栈服务，拓扑路由感知和端点子设置。双栈服务是一项与EndpointSlices一起开发的令人兴奋的新性能。他们将同时应用IPv4和IPv6地址作为服务，并依附EndpointSlices上的addressType字段按IP系列跟踪这些地址。拓扑感知路由将更新kube-proxy，以在同一区域或区域内实现路由申请。这利用了为EndpointSlice中的每个端点存储的拓扑字段。作为对此的进一步改良，咱们正在摸索端点子集的后劲。这将容许kube-proxy只观看EndpointSlices的子集。例如，这能够与拓扑路由感知联合应用，以便kube-proxy仅需监督蕴含同一区域内端点的EndpointSlice。这将提供另一个十分重要的可伸缩性改良。4 这对Endpoints API意味着什么?只管EndpointSlice API为Endpoints API提供了更新和更可扩大的代替计划，然而Endpoints API将持续被认为是广泛可用且稳固的。为Endpoints API打算的最重要的更改将波及开始截断Endpoints，否则将遇到可伸缩性问题。Endpoints API并没有隐没，然而许多新性能将依赖于EndpointSlice API。为了利用EndpointSlices提供的新的可伸缩性和性能，以后应用Endpoints的应用程序可能在未来思考反对EndpointSlices。原文链接：Scaling Kubernetes Networking With EndpointSliceshttps://kubernetes.io/blog/202 ... ices/作者: Rob Scott(Google)译者：刘博（资深云计算售前架构师）

明天咱们很快乐地发表，Lyft 的基础设施工具可扩大 UI 和 API 平台clutch已凋谢源代码，clutch使工程团队可能构建、运行和保护用户敌对的工作流，这些工作流还蕴含特定于域的平安机制和访问控制。clutch兼容多种治理平台性能（如 AWS、Envoy和 Kubernetes），强调可扩展性，因而它能够为堆栈中任何组件提供托管性能。 云计算的动静属性显著地升高了新基础设施的采纳老本。CNCF云原生计算基金会全景图跟踪了300多个以上开源我的项目和1000多个商业产品。只管各组织们能疾速采纳这些我的项目和供应商，但每种新技术都有它自带的一套配置、工具、日志和指标。为了让开发者疾速、平安地在整个堆栈中变更，须要在工具方面进行大量后期和继续的投资，而大多数组织都未能思考到这一点。所以，尽管新基础设施越来越容易采纳，但日益扩充的新组件的规模难以治理，特地是随着整个平台的复杂性和工程团队规模的增长。Clutch解决了这一难题，通过让基础设施团队向他们整个工程组织提供直观和平安的基础设施治理接口。 Clutch是一年开发周期的成绩，用来解决“Lyft”开发人员教训和工具的短板。Clutch由两个核心部件组成。go后端设计为可扩大的基础设施管制立体，将单个由protobuf驱动的API拼凑成具备通用受权，可观测性和审计日志记录的零碎。React前端是一个可插拔并且面向工作流的UI容许用户和开发者在单个窗格后创立新性能，这只须要很少的代码和很少的JavaScript常识及更少的保护工作。 1 设计和架构 在设计和架构方面，比起其余解决方案，clutch提供了不同凡响的开发人员工具空间。在我的项目开始时，咱们在构建本人的工具前对现有工具做了深入分析。采纳工具的次要目标是： •缩小均匀培修工夫。基础设施什么时候响应告警，工程师们待命时花太多工夫在浏览runbooks和操作简单的工具。 •打消意外中断。当执行保护工作时，当用户在应用runbook时漏掉正告或者删除谬误的资源（例如，他们认为没有应用，但占用了很大流量的资源），从而导致重大中断。 •强化细粒度的权限并以通用格局审计所有流动，一些权限过于宽泛，是因为供应商的访问控制不反对细粒度控件，此外，当咱们出于平安目标从各种工具收集审计日志时，很难将那些数据提炼成为如何帮忙咱们改善工具的可执行见解。 •提供一个极大简化将来工具开发的平台。以“Lyft”这样的规模，如果不思考团队外的奉献资源，我的项目范畴很大时很难胜利，咱们没有足够的资源来构建Lyft须要的每一个个性，更别说反对它了。 一开始咱们看到现有供应商UI的有余：因为不足专业化，供应商工具很慢 （并且在某些状况下是危险的）。他们须要不必要的步骤来执行常见工作，并提供超出必要的信息集。除了简略的访问控制外，通常很少有防护，后果导致经营人员可能会执行看似有害但理论升高零碎性能的操作。另外，他们兴许不太熟悉该工具从而延误补救。现实状况下，工程师每四到六周只来一次。人们很容易遗记如何应用这个工具，特地是思考到没有用特定的交互零碎状况下，又去多种执行工作。 因为碎片化和信息杂乱无序，依赖供应商工具的结果是高认知负荷。 相比之下，Clutch这样一个与供应商无关的工具能将不相干的零碎一体化为清晰，统一的用户体验，并且提供专用性能来执行常见工作，只需很少的点击和培训。 而后咱们转向开源社区，发现开源基础设施管理工具通常依然局限于单个零碎，并不是为宽泛的自定义设计的，它并不能解决认知负荷和碎片化的问题。此外，尽管有用于构建控制台的其余前端框架，但没有一个框架蕴含具备身份验证，受权，审计，可察看性，API模式和丰盛插件模型的集成后端框架。有一个很风行的继续交付平台，它解决了与Clutch雷同的首要问题（例如，升高MTTR，用户敌对的UI）然而，它须要大量的投入来运行微服务和迁徙利用到不同于咱们本人的架构上。Clutch后端性能开发简化，是通过下面列出的集成外围性能为每个API端点收费。它还开发为单个二进制文件，只须要很少的操作投入。 最初，咱们想要一个平台，能够对它进行投资，对其余外部团队来说它须要更容易了解和构建。Clutch提供一个集成的和疏导式开发模型，使其性能开发成为扼要间接的过程。除了一流的后端性能外，Clutch 的前端还为状态治理和多步表单提供了独特的形象，没有大量JavaScript 教训的基础架构团队更容易实现前端开发。 2 个性 "管制立体"模型 Envoy 代理是Lyft创立的。现在，它是最受欢迎的代理之一，部署在许多大型互联网公司，并一直推动云网络规范。咱们的团队从与大社区一起保护Envoy中学到了很多货色。Envoy用户探讨的最热门主题之一是管制立体的开发进展，特地是如何系统地集成各种不同的组件，以便Envoy可能无效地路由和报告网络流量。Envoy相似于 Clutch，它集成不同的基础设施零碎于对立的API。 Clutch采纳了许多envoy代理的外围模式，这些模式是在网络管制立体多年的工作中怀才不遇的。 像Envoy 一样，Clutch 是配置驱动、模式驱动的，并利用基于模块化扩大的架构，使其实用于各种用例，同时不影响可维护性。扩大Clutch不须要分支或重写，自定义代码能够很容易地从自定义公共或公有内部存储库编译到应用程序中。这些雷同模式使具备独特技术堆栈的大小组织可能汇集在单个代理解决方案上，无望使类似的独特组织聚焦在Clutch这样的基础设施管制立体上。 3 平安和保障 此外，Clutch附带身份验证和受权组件。OpenID Connect （OIDC） 身份验证流用于单点登录、RBAC，以及对所有操作的主动审核，并可能运行附加的输入接收器，例如Slackbot。 Clutch 还具备升高事变危险的性能。通常记录在 Runbook 中的护栏和启发式办法能够以编程形式实现。例如，咱们绝不允许用户一次将群集缩减 50% 以上，因为这种操作已经导致过失常保护时的意外中断。不久以后，咱们打算获取CPU 和其余应用数据，以便与群集信息一起显示，甚至在确定可能导致停机的状况下，限度放大规模的上限。通过将护栏和启发式办法间接施行到工具中，防止了仅仅依附于培训和运行手册来避免事变的产生。 4 部署和用户疏导 Clutch作为蕴含前端和后端的单个二进制文件进行传输，使部署工作变得很简略。许多更改能够通过配置实现，而不是从新编译新的二进制文件。 提供基础设施生命周期工具的其余零碎，则须要一组简单的微服务或迁徙到一种固有的形式治理和部署应用程序。Clutch旨在欠缺现有零碎，而不是更换它们。 5 框架和组件 Clutch由Go后端和React前端驱动。它为后端和前端开发提供了功能齐全的框架。Clutch的所有组件都是可组合的，容许应用局部框架性能或齐全自定义性能。 这样的组件和工作流体系结构让前端教训无限的开发人员在不到一个小时的开发工夫内，就能应用清晰且易于应用的分步 UI 替换轻便的工具或命令行脚本。 Clutch的前端封装提供的组件，可轻松构建统一且间断用户体验的分步工作流程，包含： •DataLayout：是一个工作流-本地状态治理控件，用于解决来自 API 调用的用户输出和数据。 •Wizard：用于向用户显示分步表单，自定义元素的 UI 插件，用于在以起码的代码以统一的形式显示丰盛的信息。 ...

只管微服务环境提供可移植性，容许更快更频繁的部署周期，甚至还能让组织创立关注于特定畛域的团队，但这也随同着对于流量治理、平安以及可观测性等需要的增长。在整个生态系统中，针对这些需要的服务网格模式的实现办法成千上万。微软始终沉闷在 Service Mesh Interface (https://smi-spec.io/) (SMI) 社区中，帮助定义一组规范可移植的 API 标准，可能实现横跨在不同服务网格之上的通用服务网格性能。供应商能够利用 SMI 来确保生态系统工具可能在不同的网格上工作，同时也容许客户抉择网格提供方。 明天咱们很快乐推出一个新的开源我的项目--Open Service Mesh (https://openservicemesh.io/) (OSM) ,一个运行于 Kubernetes 上的轻量的、可扩大的服务网格。OSM 可能让使用者在高度动态化的微服务环境中对服务到服务间的通信做到统一地治理、爱护和观测。咱们心愿 OSM 能成为一个社区主导的我的项目，这将促成 SMI 在新的和现有的 API 上的合作。咱们打算让 OSM 成为凋谢治理，这样可能轻松的与社区进行合作。因而咱们曾经提交了一份提议，来启动将 OSM 捐献给云原生计算基金会(https://cncf.io/) (CNCF) 的过程。 咱们要让 Kubernetes运维人员们可能毫不费力的装置、保护和运行 OSM；与此同时，也要让 OSM 足够简略，让整个社区都可能了解并做出奉献。 这些指标根植于客户需要之中，也将咱们引向三个根本的设计准则。首先，OSM 提供一个与SMI标准兼容的管制立体，以此来保留用户的抉择。其次，咱们应用 Envoy 作为数据立体，因为 Envoy 具备很强的社区能源。最初，OSM 背地最重要的理念是“非平缓（no cliffs）”设计，可能让 OSM 足够灵便，在简略或简单的场景下都能够间接应用 SMI 和编写 Envoy xDS API 来解决。 “很快乐 OSM 可能退出 Envoy 家族，为 Kubernetes 构建一个供应商中立的服务网格计划，并强调简便性”。--Envoy创始人Matt Klein OSM 简化了许多工作，诸如为通用部署计划的配置流量转移，应用 mLTS 来爱护服务到服务间通信的平安，为服务施行细粒度的拜访控制策略，察看用于调试和监督服务的指标，集成本地或内部证书治理解决方案，以及应用主动的 sidecar 注入将利用载入到网格中。 ...

只管微服务环境提供可移植性，容许更快更频繁的部署周期，甚至还能让组织创立关注于特定畛域的团队，但这也随同着对于流量治理、平安以及可观测性等需要的增长。在整个生态系统中，针对这些需要的服务网格模式的实现办法成千上万。微软始终沉闷在 Service Mesh Interface (https://smi-spec.io/) (SMI) 社区中，帮助定义一组规范可移植的 API 标准，可能实现横跨在不同服务网格之上的通用服务网格性能。供应商能够利用 SMI 来确保生态系统工具可能在不同的网格上工作，同时也容许客户抉择网格提供方。 明天咱们很快乐推出一个新的开源我的项目--Open Service Mesh (https://openservicemesh.io/) (OSM) ,一个运行于 Kubernetes 上的轻量的、可扩大的服务网格。OSM 可能让使用者在高度动态化的微服务环境中对服务到服务间的通信做到统一地治理、爱护和观测。咱们心愿 OSM 能成为一个社区主导的我的项目，这将促成 SMI 在新的和现有的 API 上的合作。咱们打算让 OSM 成为凋谢治理，这样可能轻松的与社区进行合作。因而咱们曾经提交了一份提议，来启动将 OSM 捐献给云原生计算基金会(https://cncf.io/) (CNCF) 的过程。 咱们要让 Kubernetes运维人员们可能毫不费力的装置、保护和运行 OSM；与此同时，也要让 OSM 足够简略，让整个社区都可能了解并做出奉献。 这些指标根植于客户需要之中，也将咱们引向三个根本的设计准则。首先，OSM 提供一个与SMI标准兼容的管制立体，以此来保留用户的抉择。其次，咱们应用 Envoy 作为数据立体，因为 Envoy 具备很强的社区能源。最初，OSM 背地最重要的理念是“非平缓（no cliffs）”设计，可能让 OSM 足够灵便，在简略或简单的场景下都能够间接应用 SMI 和编写 Envoy xDS API 来解决。 “很快乐 OSM 可能退出 Envoy 家族，为 Kubernetes 构建一个供应商中立的服务网格计划，并强调简便性”。--Envoy创始人Matt Klein OSM 简化了许多工作，诸如为通用部署计划的配置流量转移，应用 mLTS 来爱护服务到服务间通信的平安，为服务施行细粒度的拜访控制策略，察看用于调试和监督服务的指标，集成本地或内部证书治理解决方案，以及应用主动的 sidecar 注入将利用载入到网格中。 ...

1Kube-OVN社区版V1.3再降级 反对容器网络硬件加速，自定义网关，网关Qos以及更多 Kube-OVN 社区版v1.3近日全新公布，从此版本起，Kube-OVN反对基于智能网卡的硬件加速，可能大幅晋升容器网络吞吐量，升高网络提早，并且能缩小主机CPU的损耗，能够大幅晋升裸金属场景下的性能和资源利用率。同时，社区版v1.3减少了网关的性能，用户能够自定义Pod路由策略抉择集群内的特定Pod作为流量网关并进行自定义的网关性能开发，例如 EIP，计费，审计等性能。另外，网关减少了QoS管制的性能，用户能够对同一子网的总对外带宽进行动静调整。 具体性能见：https://github.com/alauda/kube ... 1.3.0 2 基于企业用户需要推出Kube-OVN企业版 性能、服务更加欠缺 Kube-OVN 开源以来，取得了少量开发者和用户的关注，并曾经在若干我的项目和理论环境中投入使用。随着多个电信级客户的认同，以及企业用户的减少，Kube-OVN在版本更迭中也更加重视稳定性、安全性、易部署等个性。所以，在Kube-OVN社区版本的根底上，Kube-OVN企业版应时而生。在网络性能、网络运维、网络安全、技术支持方面，有以下差别： 社区版 企业版 网络性能 •单集群容器网络 •IPtables网关 •单集群容器网络 •IPtables网关 •Pod EIP •多集群互通容器网络 •OVN高性能网关 •智能网卡反对 网络运维 •命令行工具 •根本连通性指标 •管制立体状态指标 •命令行工具 •根本连通性指标 •管制立体状态指标 •性能监控指标 •流量统计指标 •网络异样指标 •大屏面板 网络安全 •随社区2-3个月对立发版 •保护最近一个版本平安和Bug相干问题 •官网订阅，平安和Bug相干修复第一工夫推送 •用户版本长期反对 •定制降级计划策略 •管制立体TLS加密 •网络流量加密 技术支持 •社区反对 •技术公开课 •社区反对 •技术公开课 •原厂专家5*8技术支持 1.针对企业场景下多集群和联邦的场景，将容器其网络从单集群容器网络拓展到多集群容器网络，容器网络可跨集群互通，提供了更灵便的组网管制。 2.针对大规模集群的性能问题，应用 OVN 内置网关代替 Iptables 大幅晋升网关吞吐量能力，并提供基于网关的容器EIP能力。 3.针对裸金属性能需求提供和Mellanox智能网卡厂商集成的能力，利用智能网卡解决网络数据立体解决，晋升吞吐量性能同时升高物理机CPU的耗费。 4.更多监控指标集成，可接入第三方云杉网络DeepFlow网络监控零碎，晋升容器网络的可视化能力，更疾速的进行故障定位，流量统计，性能剖析。 5.前期运维反对，服务与产品能力同样重要，提供及时并业余的技术支持能帮忙重视平安、稳固的企业用户将问题降至最低。Kube-OVN企业版将提供官网订阅，第一工夫推送软件降级、补丁更新、装置调优等信息。提供畅通的问题反馈渠道，由原厂专家团队反对售后服务，且响应工夫（SLA）可选，满足不同水平的企业需要。 **3 Kube-OVN企业版 现推出限时收费试用** 事实上，社区版和企业版是相互共生的关系。 Kube-OVN社区版曾经集结了大量社区开源贡献者的智慧，汇聚了顶尖的技术，Kube-OVN企业版的诞生，受害于大量社区用户创立的生态，而Kube-OVN社区版又将受害于企业版的不断改进。

今年，工业互联网等新基建再次写入政府工作报告，内容从“打造工业互联网平台”，提升为更加“全面的发展工业互联网，推进智能制造”，这也意味着国家对于工业互联网建设和发展赋予了更高使命，从为单个企业赋能，需逐步扩大到为智能制造产业链、为区域经济发展助力，凸显数字经济新优势。 2018年7月，工信部印发《工业互联网平台建设及推广指南》，提出到2020年，要培育10家左右的跨行业跨领域工业互联网平台，和一批面向特定行业、特定区域的企业级工业互联网平台，这也预示着，通过平台赋能成为工业物联网助力制造业转型的第一步。 工业互联网是实现智能制造的关键基础设施，通过设备管理提升生产效率，云计算、人工智能、大数据、物联网等新技术广泛采用，是制造业从劳动密集型工厂转变为技术驱动的智能制造的关键动力。 1腾讯云布局区域工业云基地 腾讯云作为全球领先的云计算服务商，依托云计算、云数据、云运营等一体化云端服务能力，以及AI、大数据、区块链等技术优势，为企业提供覆盖终端、平台及生态构建在内的全链条服务。 腾讯云工业互联网注重区域布局，已在一些工业基础好、交通比较发达的地区，搭建工业云基地，比如永康、西安、张家港等，并采用1+N的方式，搭建了与当地产业深度结合的区域工业互联网平台，并构建以技术、人才、运营、资本四位一体的智能制造产业链，全面支撑当地制造企业的数字化、网络化、智能化转型升级。其中，1代表一套云计算基础设施，N代表多个行业工业互联网平台。 目前，多数地方性中小企业生产经营过程中，面临“三高”问题：独立购买成本高，实施成本高，运维成本高，对于是否上云和上云的价值存在信息不对称。中小企业急需一个可以拿来即用的应用生态体系，把复杂的技术通过场景化落地，降低企业信息化构建成本。腾讯云工业云平台正是瞄准了中小企业以上痛点，着力区域工业互联网平台，实现工业应用部署、订购、使用的业务闭环，降低沟通交流成本，以及自动化部署和账户打通，降低运维成本和中小企业工业应用使用门槛，推动百万企业上云。 2腾讯云云原生工业互联网解决方案 工业互联网是链接工业全系统、全产业链、全价值链，支撑工业智能化发展的关键基础设施，选择新兴的以容器、微服务架构为代表的云原生技术作为底层技术架构是极佳的选择。容器化和微服务化是工业互联网PaaS平台的主流方向。 腾讯工业互联网解决方案基于云原生技术构建的工业PaaS，在工业互联网APP应用支撑方面能够为工业企业带来以下几方面的价值： •聚焦应用的全生命周期管理，涉及开发、测试、部署、运维等全环节，提供自动部署、弹性伸缩、资源调度、负载均衡和服务发现等应用云平台所需管理功能。加速开发运维一体化，快速构建基于容器的标准化、易迁移和弹性部署、监控友好的应用系统。 •优化及业务创新，以最低的成本将新服务快速推向市场，微服务架构易于构建工业互联网，提高应用部署对基础设施的资源使用率，自动化迎接业务高峰挑战。分布式、松耦合，易于扩展的云原生微服务框架能有效降低初期开发成本。开发团队可各自快速迭代开发微服务，缩减发布周期，快速推向市场。自动化的DevOps工作方式让开发人员和运营更专注于业务实现和提高客户体验。 •建设阶段有效降低风险，通过循序渐进，从边缘到核心应用构建微服务，并逐一连接所需API，降低微服务架构落地阻力及风险；更具有灵活性和容错性，快速构建和多轮迭代之后，应用可以独立替换更新为更佳的微服务，对企业试错友好。 3区域工业云平台赋能制造业转型升级 腾讯云以云原生技术为基础引擎的工业互联网平台已经在国内多个省市的工业园区成功落地。 今年6月29日，在张家港市智能工业“双百”工程推进会上，腾讯云（张家港）工业云平台宣布正式上线运营，首批已与沙钢、永钢、陶氏、华昌、东华能源等52家企业签订智能制造系统集成协议。该平台承载了张家港市建设工业专有云、构建智能工业生态体系、建设人工智能创新中心和搭建智能工业展示平台等功能。 去年，腾讯云还与西安签署了战略合作协议，双方共建西北首家腾讯云工业云基地。发挥腾讯云工业云基地的数据优势，最终实现集产业资源协同、智能制造、智能开发、实时物流、物联监测、智能制造、航空产业大数据分析及人工智能服务于一体的综合性工业云平台。 此外，腾讯云帮助永康市打造的工业互联网平台，也已顺利部署上线，助力工业大市永康的制造业转型升级。永康以云计算技术和平台为支撑，以构建云计算应用服务体系为保障，加快推动“企业上云”，工业数字化转型全面展开。目前已服务企业用户1100多家，接纳第三方开发者3000多个，连接工业设备68万多台套，支撑应用超过1000个。 工业互联网的本质是制造业和新一代网络信息技术的深度融合，此轮竞争的背后离不开实体产业和信息技术产业的通力合作。未来，腾讯将开放技术和生态给更多地区，一方面不仅为制造业客户开放包括云计算、大数据、人工智能在内的产品和技术能力，另一方面也为龙头企业打造专属的工业互联网平台。通过打造产业互联网“朋友圈”，让更多企业享受工业互联网带来的数字化红利，也会为各地经济发展带来新的动能，重塑区域竞争格局。

下面介绍一下灵雀云开源的Kube-OVN在云原生实践方面所做的一些事情，Kube-OVN根据日常实践中遇到的问题也在不断改进。 1子网模型 Kube-OVN比较大的改动是对子网模型进行了改进，把Subnet Per Node的模型改成了Subnet Per Namespace。这样做有几点好处：首先，子网可以分布在所有节点上，避免了网络地址和主机地址的绑定。进行网络扩缩容时，不需要对整个机器集群进行改动，只需要增加或减少子网。 子网跟namespace关联时，后面会有很多独立的设置，比如每个namespace可以有独立的地址空间，对应到用户那边可能是某一个项目组，或者某个租户，这样的对应就很直接，因为它可能是租户对应到namespace，租户对应到子网，是一个紧密关联的情况。子网跟namespace绑定后，可以根据租户来定义一些防火墙的策略，网关、NAT策略，子网IPv4还是IPv6，都可以按照这个子网的级别来进行设置，而不会跟节点绑死。 2固定IP Kube-OVN还对固定IP做了全面支持。 •Pod 支持固定 IP/Mac •Workload 类型(deployment/statefulset/dae monset/job)可通过 ippool annotation 固定 IP,保证在deployment生命周期内一直在复用IP。 •StatefulSet 支持 IP 复用，生命周期内按名字复用已分配IP 。在创建StatefulSet 时不知道IP是多少，一旦StatefulSet创建完成，pod名字和IP是固定的。 我们对StatefulSet还做了一些额外的支持，在StatefulSet里面实现了默认的固定IP。这一点其实有争议，有人觉得不该这么应用，但在我们的实践中，还是把最终的选择权留给用户。如果他不需要固定IP的功能，我们完全可以按照随机分配IP的方式去做。如果用户一些部门之间存在这样的问题，需要应用或者底层去做修改，可能应用方面不想改，但是又希望上容器，要用固定IP，我们也能提供这样的能力。 3Gateway 出网的方式，在实际中会碰到应用一部分在K8s上，一部分不在，或者关联的一些系统不在K8s上，就涉及到集群内外互访的需求。我们提供几种不同的出网方式。默认是分布式网关，它和Flannel、Calico的默认模式类似，pod如果想访问外部网络，从所在node节点直接出网。但这种方式不一定能满足所有场景。 采用这种方式如果你的pod飘移，意味着出网的地址也是飘移的，加白名单或做审计都是很困难的事情，这种情况下要把整个集群所有机器都加白名单。审计时，他也不清楚究竟审计应该从哪个节点过来流量。我们做了一个namespace级别的，这个和前面的子网是绑定的，只要配置子网的网关，就可以配置出网的方式。 每个Namespace可以设置独立的Gateway节点出网。在这个节点，所有出网的流量都通过一个特定节点，相当于通过一种固定的方式出网。在外部进行审计或加白名单时，对一个节点进行处理就可以。而且这个节点可以做高可用的，现在是主备模式，如果当前的断掉，或者故障下线，可以自动切换到下一个备用的节点。 除了这两种出网方式，我们还有一个特殊的设置，pod出网要不要进行NAT，如果进行的话，相当于是以当前主机节点IP的方式出网。如果不做NAT，就相当于集群内外的互通。我们的做法还是把所有的能力都提供出来，交给用户去选择。 4性能 最后一点性能，也是大家比较关注的话题。主要从控制平面和数据平面的性能两方面讲一下Kube-OVN在工程方面的一些工作。 我们在早期主要关注控制平面的性能，Kube-OVN最早使用的是OVN控制平面。发现早期会有一些性能问题，在几千个pod时控制平面的延迟会非常严重。我们针对减缓延迟做了大量工作，比如：减少变更的规则条数，把OVN的变更进行一些合并，减少整体的变更数量，加快变更速度。 还有一个上游在做的事情，从全量更新变成增量更新。之前OVN的模式是说，网络变更需要每个节点去拉整个网络的拓扑，全量更新的话这个速度会非常慢，现在都变成增量更新，只变更新加或者更改的规则。这个变化蛮显著，按照官方的测试，之前下发上万条流表的更新要六秒左右。经过变更，只需要200到300毫秒。这个功能未来也会加入Kube-OVN，到时控制平面的支撑会达到几万或者十几万个pod或service的规模。 还有一种方式是对网络的区域进行划分。现在用户使用的K8s集群都特别大，在大的集群里，如果每个节点都要同步所有网络拓扑是很大的一个开销。我们根据租户或者可用区，把大的集群再进行网络的分区，每个分区只要遵循自己内部的一些规则，再通过特定的网关，也可以减少控制平面所需要的流表数量，降低每个节点的负担。 还有一个场景，对控制平面性能要求最高的地方在于灾难恢复的速度。平常情况下，如果集群正常运行，增删改查的频率还是可控的，如果master节点宕掉了，或整个OVN的节点、几台机器都宕掉了，再恢复时涉及到网络的同步更新。Kube-OVN有controller策略，需要对所有pod进行校验，controller启动之后，会看所有的配置是不是同步到一个最新的状态。 大家可以想象，如果有1万个pod或者service，启动时需要在OVN里重新配置。根据我们的测试，之前这个工作需要花十几分钟才能完成故障的恢复。我们对此进行了一些优化，主要有两点：第一，减少重复的网络配置。第二，对evicted，failed 等网络资源进行实时清理。 控制平面的性能完成后，我们最近在数据平面做了一些事情。首先，之前默认的情况下使用的是Geneve这种封装方式，这也是OVN推荐的一种网络封装模式。Geneve封装对物理网络拓扑要求低，封包解包存在性能损失。 我们现在也支持Vlan模式，对底层交换机是有要求的，需要底层的Vlan能够识别Kube-OVN，只需要进行轻量的封装就可以把数据包通过物理交换机的方式来进行转化。我们测试了一下性能有很大的提升，接近物理网络的性能，这是锐捷在社区提的PR。 上面两种都是基于内核的协议栈，我们现在还有一些电信、5G的场景，他们在边缘节点会有极高的网络性能的要求，常规的内核网络不能满足他们的需求。所以我们现在也支持DPDK协议栈，容器挂载 vhost-user socket，容器内可运行高性能DPDK 应用。 5监控和故障排查 前面的性能等功能是大家在选型时比较关注的点，但实际中会发现运维和监控是更为重要的能力。如果出了问题会影响很多部门对容器网络的信心，所以Kube-OVN集成了很多常用的工具，包括常用的Tcpdump集成到了插件里，方便把流量导出来。还有ovn-trace，如果网络从一个点到另一个点不通，可以通过tracing工具查看数据包从源到目的地的逻辑链是否存在问题。 此外还集成了大量监控，可能大家都是看某个容器的网络监控，比如带宽、错误率等，我们增加了常规的监控，从整体上提升网络质量的监控。主要分为以下几个维度： •Pod-> Pod •Pod-> Node •Pod-> Service •Pod-> DNS •Pod-> External Address 我们会有定期的监测，包括延迟、连通性的质量，所有的数据都打到Prometheus & Grafana 里面，帮助运维和网络的管理人员，实时看到当前网络的质量，而不需要等到应用出现问题再去追溯到网络。而且当应用出现问题，也可以通过监控数据，判断到底是容器网络的问题，还是应用层面的问题。还有一些流量走向的工作，所有的容器流量进行镜像，这样传统的一些分析工具，比如细粒度的流量分析、深度检测、安全检测，通过流量的方式来做一些更细粒度的网络性能、质量的监控。 6用户案例 ...