通过华为云云计算实践——使用区块链相关技术实现区块链部署模拟资产变化的实践可知：区块链具有去中心化，透明度高，安全性，自治性等优点。大致分为四步关键流程：（1）订购区块链服务 ：创建VPC，创建CCE，创建BCS。（2）安装及实例化链代码。（3）配置并部署应用：证书下载，SDK配置下载，部署应用。（4）结果验证。从本次实践应用中我们可以得出，区块链的优点如下：（1）去中心化，改变了传统的中心化系统存在单点故障和不可靠性的问题，使得交易记录、数字身份、智能合约等数据的存储和管理不依赖于中心机构，可以在整个网络中共享和验证。（2）透明度：任何人都可以查看分布式账本中的交易记录。这样一来，区块链技术可以提高数据的透明度，减少欺诈行为。（3）安全性：每个区块链节点都会在网络中验证交易并记录到分布式账本中。这些交易记录使用了密码学算法进行加密，使得记录不可篡改，从而保证了交易的安全性。（4）自治性：采用基于协商一致的规范和协议，使各参与方在不需要信任任何人的环境下进行自由安全的交易，排除人为干扰因素达到高度自治。

亲爱的开发者：您好！在技术不断迭代进化的今天提升编码技能、了解技术前沿对开发者来说尤为重要那么作为开发者的你喜欢什么样的学习形式？觉得现有学习平台有何不便之处？欢迎填写问卷，参与调研让我们了解开发者的学习痛点以便后续更精准的提供有效内容~戳下方问卷填写：https://survey.huaweicloud.com/survey/#/qtn?id=d95fc8286afd427d832950ad323328b8&utm_medium=banner1（耗时大约3-5分钟）活动时间：2023.12.5-2023.1.151、如果你对PaaS、媒体、云原生、EI感兴趣，欢迎观看收藏往期专家直播👉【DTSE Tech Talk】直播回顾汇总，开发者必读的技术公开课干货大合集！2、如果你想持续关注DTSE Tech Talk（华为云开发者联盟推出的技术公开课），可戳下方链接了解👉 DTSE Tech Talk 华为云直播

12月奖励推广规则重要信息提示：1、邀请用户注册并完成购买云产品可获基础现金奖励2、本月云推官参加“2023年12月额外奖励活动”，可以自动叠加“基础现金奖励”。①本月新加入云推官本月最多可获得5万元现金奖励（基础奖励）+2000元购物卡盲盒（额外活动推荐客户数奖） + 华为P40 Pro+手机（额外活动消费金额奖）②已经在推广的云推官本月最多可获得8万元现金奖励（基础奖励）+2000元购物卡盲盒（额外活动推荐客户数奖） +华为P40 Pro+手机（额外活动消费金额奖）3、新上线产品“云耀云服务器L实例”，该新品的订单中，以下规格不返利：①应用超市②固定带宽中的“动态BGP流量包”规格对应订单截图举例：​参与本月活动，需先点此加入成为云推官：加入条件：奖励推广活动限华为云官网已实名个人客户参与（渠道以及子客户，NA 客户，以及有专属商务经理对接的客户不参与此活动，且产生的订单不计入返利范围），点击“立即加入云推官”按钮，即刻加入活动开始推荐。有效推荐：推荐产生关联仅适用于新注册用户，关联关系建立后的30天内产生的有效新购订单的累计付费可计入返利，订单实付金额＞0元即可计入奖励统计。沟通途径：如有任何推广问题，您可随时添加华为云奖励推广活动企业微信随时沟通，添加企业微信可及时接收最新活动及其他相关动态。本月激励汇总一、基础现金奖励（0元起返）规则介绍：cid:link_1本月新加入云推官最高奖励比例31%，单月奖励封顶5万元老云推官最高奖励比例34%，单月奖励封顶8万元​二、2023年12月额外奖励活动活动时间：2023年12月1日0点 - 2023年12月31日24点活动要求：1、需要加入华为云奖励推广计划成为云推官。2、云推官需在活动时间内通过指定活动报名页进行报名，方可成功参加本月活动。3、云推官成功推荐的客户，注册和购买时间需要在活动限定时间内（2023年12月1日0点 - 2023年12月31日24点）。4、本月活动礼品中的“购物卡”为京东购物卡，“购物卡盲盒”的实际到手面值≥活动描述面值。5、云推官在活动报名页填写正确的邮箱信息，以便后续正常发放和接收“购物卡”。6、活动发放的礼品卡，云推官需在接收后30天内完成绑定，如出现绑定异常，需联系京东客服自行解决。7、如有任何活动问题，您可通过华为云奖励推广官方企业微信沟通交流。活动一：12月推荐客户数额外激励活动条件：条件说明：1、云推官推荐成功的客户，购买的产品需要在《可参加返利产品明细表》中，且订单类型为包年包月或一次性。2、云推官推荐单客户的现金付费金额≥41元。3、礼品数量有限，需先报名参加活动，如果对应礼品区间参与人数大于礼品数，则按“推荐金额”排序向后顺延。云推官专属特惠产品页符合本活动产品举例（更多产品及配置可查看云途观专属特惠页）：活动二：11月消费金额额外激励活动条件：条件说明：1、全体云推官，本月推荐付费客户数≥2，且单客户的现金付费≥1000元，可得实物礼品。2、云推官推荐成功的客户，购买的产品需要在《可参加返利产品明细表》中；3、礼品数量有限，需报名参加，如果对应礼品区间参与人数大于礼品数，则按“推荐金额高→低”排序向后顺延。云推官专属特惠产品页符合本活动的特惠产品举例（更多产品及配置可查看云推官专属特惠页）：

活动时间：2023年12月1日0点 - 2023年12月31日24点已加入云推官点此快速报名参加本月活动重要提示：1、需要加入华为云奖励推广计划成为云推官。2、云推官需在活动时间内通过活动报名页进行报名，方可成功参加本月活动。3、云推官成功推荐的客户，注册和购买时间需要在活动限定时间内（2023年12月1日0点 - 2023年12月31日24点）。4、本月云推官参加“2023年12月额外奖励活动”，可以自动叠加“基础现金奖励”。。①本月新加入云推官最多可获得5万元现金奖励（基础奖励）+2000元购物卡盲盒（额外活动推荐客户数奖） + 华为P40 Pro+手机（额外活动消费金额奖）②已经在推广的云推官最多可获得8万元现金奖励（基础奖励）+2000元购物卡盲盒（额外活动推荐客户数奖） + P40 Pro+手机（额外活动消费金额奖）5、本月活动礼品中的“购物卡”为京东购物卡，以“盲盒”形式发放，实际到手面值≥活动描述面值。6、云推官在活动报名页填写正确的邮箱信息，以便后续正常发放和接收“购物卡”。7、活动发放的礼品卡，云推官需在接收后30天内完成绑定，如出现异常，请联系京东客服解决。8、如有任何活动问题，您可通过华为云奖励推广官方企业微信沟通交流。活动一：12月推荐客户数额外激励活动条件：条件说明：1、云推官推荐成功的客户，购买的产品需要在《可参加返利产品明细表》中，且订单类型为包年包月或一次性。2、云推官推荐单客户的现金付费金额≥41元。3、礼品数量有限，需先报名参加活动，如果对应礼品区间参与人数大于礼品数，则按“推荐金额”排序向后顺延。活动二：12月消费金额额外激励活动条件：条件说明：1、全体云推官，本月推荐付费客户数≥2，且单客户的现金付费≥1000元，可得实物礼品。2、云推官推荐成功的客户，购买的产品需要在《可参加返利产品明细表》中；3、礼品数量有限，需报名参加，如果对应礼品区间参与人数大于礼品数，则按“推荐金额高→低”排序向后顺延。奖励推广活动规则：1. 本活动仅限华为云官网已实名个人用户参与（渠道以及子客户，NA 客户，以及有专属商务经理对接的客户不参与此活动，且产生的订单不计入返利范围）。2. 购买储值卡订单及消费储值卡余额所产生的订单不计入业绩，使用信用账户、现金券、代金券的扣款部分不计入业绩，业绩只计入扣款后实付金额部分。3.适用产品：可参与返现的产品有弹性云服务器、虚拟私有云、云硬盘、云数据库、企业主机安全、 DDoS高防、分布式缓存服务、管理检测与响应等90款产品。其他产品均不参加返利，另储值卡、资源包、按需套餐包付费订单类型也不纳入返利计算，点击查看更多返利产品4..当月的有效推荐奖励，我们会在次月最后一天统计出您的推广业绩，然后您可以申付到您绑定的银行卡，申付的到账时间一般为3-7个工作日。2020年12月起，推广返利分四个月发放到云推官已通过商业信息认证的银行卡内（返利发放比例为：20%、20% 、 20%、40%），请您务必绑定正确的银行卡信息，以确保返现奖励正常发放。5. 推荐产生关联仅适用于新注册用户，关联关系建立后的30天内（推荐周期）产生的有效新购订单的累计付费可计入返利，推荐金额为活动期间的实际付费金额（续订订单不计为有效订单）。6. 活动的返利结算周期为自然月 。用户可在用户中心—我的推荐查看返利订单及详情。7. 新购实付订单金额＞0元的用户方为有效用户，2020年12月起，每月的推广返利将会分四个月发放到您的银行卡内。8. 参与返利的订单将在次月6日被锁定，锁定期为订单时长（锁定时不得降配和退款）。9. 若云推官与用户存在以下任何一种情况：同手机号、同邮箱、同身份证、同设备注册或登录的，则产生的订单不能参与推荐返利。10. 云推官在主体名下（身份证主体）只能有一个华为云账号加入奖励推广计划，注册的其他账号无法加入。11. 推云推官推荐的用户在有效推荐周期内，且在订单锁定前，用户的身份发生变化（如变更为渠道及其子客户,NA客户等），则该用户的推荐无效。12. 如云推官的一个被推荐主体（身份证主体）有注册多个账号与云推官进行关联，则只允许一个账号关联有效，其他关联关系会失效，有效关联账号以最早注册的账号为准。13. 禁止链接劫持、强制**、违反法律法规等的非正当方式推广，须退回佣金；如云推官、用户违反 华为云用户协议，则不返利。14. 本次优惠活动与华为云站内及站外其他优惠活动不重叠，赠送金额不兑现、不开票。15. 华为云员工以及伙伴员工不能参与奖励推广计划。16. 如有问题，可直接发送邮件到 cloudcps@huawei.com 进行咨询。17. 所有参加本活动的用户，均视为认可并同意遵守《华为云用户协议》以及《华为云合作推广协议》。* 推荐奖励说明：1. 累计付费阶梯奖励、额外任务奖励、连续推广奖励的“返点比例”可叠加。2. 有效推广月份：累计推广有效付费金额＞0元的月份。3. 参与门槛：自2020年8月1日起，用户每月有效新购订单实付金额＞0为有效推广用户。4. 请云推官务必绑定正确的银行卡信息，以确保返现奖励正常发放。5. 自2020年8月1日起，华为云奖励推广计划奖励升级为现金返利，8月以后参与推广产生的订单即可获得现金返利，8月前推广的订单依旧按历史规则返京东E卡或代金券。

前面我们了解了位于服务网格内部的应用应如何访问网格外部的 HTTP 和 HTTPS 服务，知道如何通过 ServiceEntry 对象配置 Istio 以受控的方式访问外部服务，这种方式实际上是通过 Sidecar 直接调用的外部服务，但是有时候我们可能需要通过专用的 Egress Gateway 服务来调用外部服务，这种方式可以更好的控制对外部服务的访问。Istio 使用 Ingress 和 Egress Gateway 配置运行在服务网格边缘的负载均衡，Ingress Gateway 允许定义网格所有入站流量的入口。Egress Gateway 是一个与 Ingress Gateway 对称的概念，它定义了网格的出口。Egress Gateway 允许我们将 Istio 的功能（例如，监视和路由规则）应用于网格的出站流量。使用场景比如有一个对安全要求非常严格的团队，要求服务网格所有的出站流量必须经过一组专用节点。专用节点运行在专门的机器上，与集群中运行应用程序的其他节点隔离，这些专用节点用于实施 Egress 流量的策略，并且受到比其余节点更严密地监控。另一个使用场景是集群中的应用节点没有公有 IP，所以在该节点上运行的网格服务都无法访问互联网，那么我们就可以通过定义 Egress gateway，将公有 IP 分配给 Egress Gateway 节点，用它引导所有的出站流量，可以使应用节点以受控的方式访问外部服务。接下来我们就来学习下在 Istio 中如何配置使用 Egress Gateway。准备工作如果你使用的 demo 这个配置文件安装 Istio，那么 Egress Gateway 已经默认安装了，可以通过下面的命令来查看：$ kubectl get pod -l istio=egressgateway -n istio-system NAME READY STATUS RESTARTS AGE istio-egressgateway-556f6f58f4-hkzdd 1/1 Running 0 14d如果没有 Pod 返回，可以通过下面的步骤来部署 Istio Egress Gateway。如果你使用 IstioOperator 安装 Istio，请在配置中添加以下字段：spec: components: egressGateways: - name: istio-egressgateway enabled: true否则使用如下的 istioctl install 命令来安装：$ istioctl install <flags-you-used-to-install-Istio> \ --set components.egressGateways[0].name=istio-egressgateway \ --set components.egressGateways[0].enabled=true同样我们还是使用 sleep 示例做为发送请求的测试源，如果启用了自动 Sidecar 注入，运行以下命令部署示例应用程序：kubectl apply -f samples/sleep/sleep.yaml否则，在使用以下命令部署 sleep 应用程序之前，手动注入 Sidecar：kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)为了发送请求，您需要创建 SOURCE_POD 环境变量来存储源 Pod 的名称：export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})用 Egress gateway 发起 HTTP 请求首先创建一个 ServiceEntry 对象来允许流量直接访问外部的 edition.cnn.com 服务。apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: cnn spec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https protocol: HTTPS resolution: DNS发送 HTTPS 请求到 https://edition.cnn.com/politics 验证 ServiceEntry 是否已正确应用。$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # 输出如下内 HTTP/1.1 301 Moved Permanently # ...... location: https://edition.cnn.com/politics # ...... HTTP/2 200 Content-Type: text/html; charset=utf-8 # ......然后为 edition.cnn.com 的 80 端口创建一个 egress Gateway，并为指向 Egress Gateway 的流量创建一个 DestinationRule 规则，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway # 匹配 Egress Gateway Pod 的标签 servers: - port: number: 80 name: http protocol: HTTP hosts: - edition.cnn.com # 也支持通配符 * 的形式 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local # 目标规则为 Egress Gateway subsets: - name: cnn # 定义一个子集 cnn，没有指定 labels，则 subset 会包含所有符合 host 字段指定的服务的 Pod在上面的对象中我们首先定义了一个 Gateway 对象，不过这里我们定义的是一个 Egress Gateway，通过 istio: egressgateway 匹配 Egress Gateway Pod 的标签，并在 servers 中定义了 edition.cnn.com 服务的 80 端口。然后定义了一个 DestinationRule 对象，指定了目标规则为 istio-egressgateway.istio-system.svc.cluster.local，并定义了一个子集 cnn。这里的子集名称是 cnn，但没有指定 labels。这意味着，这个 subset 会涵盖所有属于 istio-egressgateway.istio-system.svc.cluster.local 服务的 Pod。这种情况下，subset 的作用主要是为了在其他 Istio 配置中提供一个方便的引用名称，而不是为了区分不同的 Pod 子集。如何再定义一个 VirtualService 对象将流量从 Sidecar 引导至 Egress Gateway，再从 Egress Gateway 引导至外部服务，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - istio-egressgateway # Egress Gateway - mesh # 网格内部的流量 http: - match: - gateways: - mesh # 这条规则适用于从服务网格内发出的流量 port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local # 流量将被路由到 egress gateway subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway # 这条规则适用于通过 istio-egressgateway 的流量 port: 80 route: - destination: host: edition.cnn.com # 流量将被路由到外部服务 port: number: 80 weight: 100在上面的 VirtualService 对象中通过 hosts 指定 edition.cnn.com，表示该虚拟服务用于该服务的请求，gateways 字段中定义了 istio-egressgateway 和 mesh 两个值，istio-egressgateway 是上面我们定义的 Egress Gateway，mesh 表示该虚拟服务用于网格内部的流量，也就是说这个虚拟服务指定了如何处理来自服务网格内部以及通过 istio-egressgateway 的流量。mesh 是一个特殊的关键字，在 Istio 中表示服务网格内的所有 Sidecar 代理。当使用 mesh 作为网关时，这意味着 VirtualService 中定义的路由规则适用于服务网格内的所有服务，即所有装有 Istio sidecar 代理的服务。http 字段中定义了两个 match，第一个 match 用于匹配 mesh 网关，第二个 match 用于匹配 istio-egressgateway 网关，然后在 route 中定义了两个 destination，第一个 destination 用于将流量引导至 Egress Gateway 的 cnn 子集，第二个 destination 用于将流量引导至外部服务。总结来说，这个 VirtualService 的作用是控制服务网格内部到 edition.cnn.com 的流量。当流量起始于服务网格内时，它首先被路由到 istio-egressgateway，然后再路由到 edition.cnn.com，这种配置有助于统一和控制从服务网格内部到外部服务的流量，可以用于流量监控、安全控制或实施特定的流量策略。应用上面的资源对象后，我们再次向 edition.cnn.com 的 /politics 端点发出 curl 请求：$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # ...... HTTP/1.1 301 Moved Permanently location: https://edition.cnn.com/politics # ...... HTTP/2 200 Content-Type: text/html; charset=utf-8 # ......正常和前面的一次测试输出结果是一致的，但是这次在请求是经过 istio-egressgateway Pod 发出的，我们可以查看日志来验证：kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail正常会看到一行类似于下面这样的内容：[2023-11-15T08:48:38.683Z] "GET /politics HTTP/2" 301 - via_upstream - "-" 0 0 204 203 "10.244.1.73" "curl/7.81.0-DEV" "6c2c4550-92d4-955c-b6cb-83bf2b0e06f4" "edition.cnn.com" "151.101.3.5:80" outbound|80||edition.cnn.com 10.244.2.184:46620 10.244.2.184:8080 10.244.1.73:49924 - -因为我们这里只是将 80 端口的流量重定向到 Egress Gateway 了，所以重定向后 443 端口的 HTTPS 流量将直接进入 edition.cnn.com，所以没有看到 443 端口的日志，但是我们可以通过 SOURCE_POD 的 Sidecar 代理的日志来查看到：$ kubectl logs "$SOURCE_POD" -c istio-proxy | tail # ...... [2023-11-15T08:55:55.513Z] "GET /politics HTTP/1.1" 301 - via_upstream - "-" 0 0 191 191 "-" "curl/7.81.0-DEV" "12ce15aa-1247-9b7e-8185-4224f96f5ea0" "edition.cnn.com" "10.244.2.184:8080" outbound|80|cnn|istio-egressgateway.istio-system.svc.cluster.local 10.244.1.73:49926 151.101.195.5:80 10.244.1.73:41576 - - [2023-11-15T08:55:55.753Z] "- - -" 0 - - - "-" 839 2487786 1750 - "-" "-" "-" "-" "151.101.195.5:443" outbound|443||edition.cnn.com 10.244.1.73:45246 151.101.67.5:443 10.244.1.73:42998 edition.cnn.com -用 Egress gateway 发起 HTTPS 请求上面我们已经学习了如何通过 Egress Gateway 发起 HTTP 请求，接下来我们再来学习下如何通过 Egress Gateway 发起 HTTPS 请求。原理都是一样的，只是我们需要在相应的 ServiceEntry、Egress Gateway 和 VirtualService 中指定 TLS 协议的端口 443。首先为 edition.cnn.com 定义 ServiceEntry 服务：apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: cnn spec: hosts: - edition.cnn.com ports: - number: 443 name: tls protocol: TLS resolution: DNS应用该资源对象后，发送 HTTPS 请求到 https://edition.cnn.com/politics，验证该 ServiceEntry 是否已正确生效。$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics ... HTTP/2 200 Content-Type: text/html; charset=utf-8 ...接下来同样的方式为 edition.cnn.com 创建一个 Egress Gateway。除此之外还需要创建一个目标规则和一个虚拟服务，用来引导流量通过 Egress Gateway，并通过 Egress Gateway 与外部服务通信。apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 443 name: tls protocol: TLS hosts: - edition.cnn.com tls: mode: PASSTHROUGH # 透传 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - mesh - istio-egressgateway tls: - match: - gateways: - mesh port: 443 sniHosts: - edition.cnn.com route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 443 - match: - gateways: - istio-egressgateway port: 443 sniHosts: - edition.cnn.com route: - destination: host: edition.cnn.com port: number: 443 weight: 100上面对象中定义的 Gateway 对象和前面的一样，只是将端口改为了 443，然后在 tls 中指定了 mode: PASSTHROUGH，表示该 Gateway 对象用于 TLS 协议的请求。然后在后面的 VirtualService 对象中就是配置 spec.tls 属性，用于指定 TLS 协议的请求的路由规则，配置方法和前面 HTTP 方式类似，只是注意要将端口改为 443，并且在 match 中指定 sniHosts 为 edition.cnn.com，表示该虚拟服务用于处理 edition.cnn.com 的 TLS 请求。应用上面的资源对象后，我们现在发送 HTTPS 请求到 https://edition.cnn.com/politics，输出结果应该和之前一样。$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics ... HTTP/2 200 Content-Type: text/html; charset=utf-8 ...检查 Egress Gateway 代理的日志，则打印日志的命令是：kubectl logs -l istio=egressgateway -n istio-system应该会看到类似于下面的内容：[2023-11-15T08:59:55.513Z] "- - -" 0 - 627 1879689 44 - "-" "-" "-" "-" "151.101.129.67:443" outbound|443||edition.cnn.com 172.30.109.80:41122 172.30.109.80:443 172.30.109.112:59970 edition.cnn.com到这里我们就实现了通过 Egress Gateway 发起 HTTPS 请求。最后记得清理上面创建的资源对象：$ kubectl delete serviceentry cnn $ kubectl delete gateway istio-egressgateway $ kubectl delete virtualservice direct-cnn-through-egress-gateway $ kubectl delete destinationrule egressgateway-for-cnn需要注意的是，Istio 无法强制让所有出站流量都经过 Egress Gateway， Istio 只是通过 Sidecar 代理实现了这种流向。攻击者只要绕过 Sidecar 代理， 就可以不经 Egress Gateway 直接与网格外的服务进行通信，从而避开了 Istio 的控制和监控。出于安全考虑，集群管理员和云供应商必须确保网格所有的出站流量都要经过 Egress Gateway。这需要通过 Istio 之外的机制来满足这一要求。例如，集群管理员可以配置防火墙，拒绝 Egress Gateway 以外的所有流量。Kubernetes NetworkPolicy 也能禁止所有不是从 Egress Gateway 发起的出站流量，但是这个需要 CNI 插件的支持。此外，集群管理员和云供应商还可以对网络进行限制，让运行应用的节点只能通过 gateway 来访问外部网络。要实现这一限制，可以只给 Gateway Pod 分配公网 IP，并且可以配置 NAT 设备， 丢弃来自 Egress Gateway Pod 之外的所有流量。Egress TLS Origination接下来我们将学习如何通过配置 Istio 去实现对发往外部服务的流量的 TLS Origination（TLS 发起）。若此时原始的流量为 HTTP，则 Istio 会将其转换为 HTTPS 连接。TLS Origination 的概念前面我们也已经介绍过了。TLS Origination假设有一个传统应用正在使用 HTTP 和外部服务进行通信，如果有一天突然有一个新的需求，要求必须对所有外部的流量进行加密。此时，使用 Istio 便可通过修改配置实现此需求，而无需更改应用中的任何代码。该应用可以发送未加密的 HTTP 请求，由 Istio 为请求进行加密。从应用源头发起未加密的 HTTP 请求，并让 Istio 执行 TLS 升级的另一个好处是可以产生更好的遥测并为未加密的请求提供更多的路由控制。下面我们就来学习下如何配置 Istio 实现 TLS Origination。同样我们这里使用 sleep 示例应用来作为测试源，如果启用了自动注入 Sidecar，那么可以直接部署 sleep 应用：kubectl apply -f samples/sleep/sleep.yaml否则在部署 sleep 应用之前，必须手动注入 Sidecar：kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)创建一个环境变量来保存用于将请求发送到外部服务 Pod 的名称：export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})▍配置对外部服务的访问首先使用 ServiceEntry 对象来配置对外部服务 edition.cnn.com 的访问。这里我们将使用单个 ServiceEntry 来启用对服务的 HTTP 和 HTTPS 访问。创建一个如下所示的 ServiceEntry 对象：apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: edition-cnn-com spec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https-port protocol: HTTPS resolution: DNS上面的 ServiceEntry 对象中我们指定了 edition.cnn.com 服务的主机名，然后在 ports 中指定了需要暴露的端口及其属性，表示该 ServiceEntry 对象代表对 edition.cnn.com 的访问，这里我们定义了 80 和 443 两个端口，分别对应 http 和 https 服务，resolution: DNS 定义了如何解析指定的 hosts，这里我们使用 DNS 来解析。直接应用该资源对象，然后向外部的 HTTP 服务发送请求：$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # 输出如下结果 HTTP/1.1 301 Moved Permanently # ...... location: https://edition.cnn.com/politics HTTP/2 200 content-type: text/html; charset=utf-8 # ......上面我们在使用 curl 命令的时候添加了一个 -L 标志，该标志指示 curl 将遵循重定向。在这种情况下，服务器将对到 http://edition.cnn.com/politics 的 HTTP 请求进行重定向响应，而重定向响应将指示客户端使用 HTTPS 向 https://edition.cnn.com/politics 重新发送请求，对于第二个请求，服务器则返回了请求的内容和 200 状态码。尽管 curl 命令简明地处理了重定向，但是这里有两个问题。第一个问题是请求冗余，它使获取 http://edition.cnn.com/politics 内容的延迟加倍，第二个问题是 URL 中的路径（在本例中为 politics）被以明文的形式发送。如果有人嗅探你的应用与 edition.cnn.com 之间的通信，他将会知晓该应用获取了此网站中哪些特定的内容。出于隐私的原因，我们可能希望阻止这些内容被嗅探到。通过配置 Istio 执行 TLS 发起，则可以解决这两个问题。▍用于 egress 流量的 TLS 发起为 edition.cnn.com 创建一个出口网关，端口为 80，接收 HTTP 流量，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 80 name: tls-origination-port protocol: HTTP hosts: - edition.cnn.com然后为 istio-egressgateway 创建一个 DestinationRule 对象，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn接着我们只需要创建一个 VirtualService 对象，将流量从 Sidecar 引导至 Egress Gateway，再从 Egress Gateway 引导至外部服务，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - istio-egressgateway # Egress Gateway - mesh # 网格内部的流量 http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway port: 80 route: - destination: host: edition.cnn.com port: number: 443 # 443 端口 weight: 100 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: originate-tls-for-edition-cnn-com spec: host: edition.cnn.com trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com需要注意的是上面最后针对 edition.cnn.com 的 DestinationRule 对象，在 trafficPolicy 中指定了 portLevelSettings 用于对不同的端口定义不同的流量策略，这里我们定义了 443 端口的 tls 模式为 SIMPLE，表示当访问 edition.cnn.com 的 HTTP 请求时执行 TLS 发起。应用上面的资源对象，然后再次向 http://edition.cnn.com/politics 发送 HTTP 请求：$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # 直接输出200状态码 HTTP/1.1 200 OK content-length: 2474958 content-type: text/html; charset=utf-8 # ......这次将会收到唯一的 200 OK 响应，因为 Istio 为 curl 执行了 TLS 发起，原始的 HTTP 被升级为 HTTPS 并转发到 edition.cnn.com。服务器直接返回内容而无需重定向，这消除了客户端与服务器之间的请求冗余，使网格保持加密状态，隐藏了你的应用获取 edition.cnn.com 中 politics 端点的信息。如果我们在代码中有去访问外部服务，那么我们就可以不用修改代码了，只需要通过配置 Istio 来获得 TLS 发起即可，而无需更改一行代码。到这里我们就学习了如何通过配置 Istio 实现对外部服务的 TLS 发起。▍TLS 与 mTLS 基本概念前面我们学习了如何通过配置 Istio 实现对外部服务的 TLS 发起，这里其实还有一个 mTLS 的概念呢，由于 TLS 本身就比较复杂，对于双向 TLS（mTLS）就更复杂了。TLS 是一个连接层协议，旨在为 TCP 连接提供安全保障。TLS 在连接层工作，可以与任何使用 TCP 的应用层协议结合使用。例如，HTTPS 是 HTTP 与 TLS 的结合（HTTPS 中的 S 指的是 SSL，即 TLS 的前身），TLS 认证的流程大致如下所示：首先向第三方机构 CA 提交组织信息、个人信息(域名)等信息并申请认证。CA 通过多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。如信息审核通过，CA 会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。客户端向服务端发出请求时，服务端返回证书文件。客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性。客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任 CA 的证书信息(包含公钥)，比如浏览器基本上都带有知名公共 CA 机构的证书，如 Verisign、Digicert 等，这些证书在发布时被打包在一起，当我们下载浏览器时，就经把正确的证书放进了浏览器，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。认证过程当然 HTTPS 的工作流程和这个过程基本就一致了：1.客户端发起一个 HTTPS 请求。2.服务端把配置好的证书返回给客户端。3.客户端验证证书：比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在 CRL 吊销列表里面，它的上一级证书是否有效等。4.客户端使用伪随机数生成对称密钥，并通过证书里服务器的公钥进行加密，后续使用该对称密钥进行传输信息。5.服务端使用自己的私钥解密这个消息，得到对称密钥。至此，客户端和服务端都持有了相同的对称密钥。6.服务端使用对称密钥加密明文内容 A，发送给客户端。7.客户端使用对称密钥解密响应的密文，得到明文内容 A。8.客户端再次发起 HTTPS 的请求，使用对称密钥加密请求的明文内容 B，然后服务器使用对称密钥解密密文，得到明文内容 B。HTTPS 工作流程当然双向 TLS 就更为复杂了，Mutual TLS（双向 TLS），或称 mTLS，对于常规的 TLS，只需要服务端认证，mTLS 相对来说有一个额外的规定：客户端也要经过认证。在 mTLS 中，客户端和服务器都有一个证书，并且双方都使用它们的公钥/私钥对进行身份验证。TLS 保证了真实性，但默认情况下，这只发生在一个方向上：客户端对服务器进行认证，但服务器并不对客户端进行认证。为什么 TLS 的默认只在一个方向进行认证？因为客户端的身份往往是不相关的。例如我们在访问优点知识的时候，你的浏览器已经验证了要访问的网站服务端的身份，但服务端并没有验证你的浏览器的身份，它实际上并不关心你的浏览器的身份，这对于互联网上的 Web 项目来说足够了。但是在某些情况下，服务器确实需要验证客户端的身份，例如，当客户端需要访问某些敏感数据时，服务器可能需要验证客户端的身份，以确保客户端有权访问这些数据，这就是 mTLS 的用武之地，mTLS 是保证微服务之间跨服务通信安全的好方法。首先，你想要安全的通信。当我们把我们的应用程序拆分为多个服务时，我们最终会在这些服务之间的网络上发送敏感数据。任何能够进入网络的人都有可能读取这些敏感数据并伪造请求。其次，你关心客户端的身份。首先，你要确保你能知道调用是什么时候发生的，以便进行诊断，并正确记录指标等事项。此外，你可能想对这些身份进行授权（允许 A 调用 B 吗）。当然授权是另外的话题了。接下来我们就来测试下如何通过 egress 网关发起双向 TLS 连接。▍通过 egress 网关发起双向 TLS 连接首先使用 openssl 命令生成客户端和服务器的证书与密钥，为你的服务签名证书创建根证书和私钥：openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt # 生成 CA 证书和私钥为 my-nginx.mesh-external.svc.cluster.local 创建证书和私钥：# 为 my-nginx.mesh-external.svc.cluster.local 创建私钥和证书签名请求 $ openssl req -out my-nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-nginx.mesh-external.svc.cluster.local/O=some organization" # 使用 CA 公钥和私钥以及证书签名请求为 my-nginx.mesh-external.svc.cluster.local 创建证书 $ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-nginx.mesh-external.svc.cluster.local.csr -out my-nginx.mesh-external.svc.cluster.local.crt然后生成客户端证书和私钥：# 为 client.example.com 创建私钥和证书签名请求 $ openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization" # 使用相同的 CA 公钥和私钥以及证书签名请求为 client.example.com 创建证书 $ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt接着我们来部署一个双向 TLS 服务器，为了模拟一个真实的支持双向 TLS 协议的外部服务，我们在 Kubernetes 集群中部署一个 NGINX 服务，该服务运行在 Istio 服务网格之外，比如运行在一个没有开启 Istio Sidecar proxy 注入的命名空间中。创建一个命名空间 mesh-external 表示 Istio 网格之外的服务，注意在这个命名空间中，Sidecar 自动注入是没有开启的，不会在 Pod 中自动注入 Sidecar proxy。kubectl create namespace mesh-external然后创建 Kubernetes Secret，保存服务器和 CA 的证书。$ kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt $ kubectl create -n mesh-external secret generic nginx-ca-certs --from-file=example.com.crt生成 NGINX 服务器的配置文件：$ cat <<\EOF > ./nginx.conf events { } http { log_format main '$remote_addr - $remote_user [$time_local] $status ' '"$request" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log; server { listen 443 ssl; root /usr/share/nginx/html; index index.html; server_name my-nginx.mesh-external.svc.cluster.local; ssl_certificate /etc/nginx-server-certs/tls.crt; ssl_certificate_key /etc/nginx-server-certs/tls.key; ssl_client_certificate /etc/nginx-ca-certs/example.com.crt; ssl_verify_client on; } } EOF生成 Kubernetes ConfigMap 保存 NGINX 服务器的配置文件：kubectl create configmap nginx-configmap -n mesh-external --from-file=nginx.conf=./nginx.conf然后就可以部署 NGINX 服务了：$ kubectl apply -f - <<EOF apiVersion: v1 kind: Service metadata: name: my-nginx namespace: mesh-external labels: run: my-nginx spec: ports: - port: 443 protocol: TCP selector: run: my-nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx namespace: mesh-external spec: selector: matchLabels: run: my-nginx template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 443 volumeMounts: - name: nginx-config mountPath: /etc/nginx readOnly: true - name: nginx-server-certs mountPath: /etc/nginx-server-certs readOnly: true - name: nginx-ca-certs mountPath: /etc/nginx-ca-certs readOnly: true volumes: - name: nginx-config configMap: name: nginx-configmap - name: nginx-server-certs secret: secretName: nginx-server-certs - name: nginx-ca-certs secret: secretName: nginx-ca-certs EOF现在如果我们在网格内部去直接访问这个 my-nginx 服务，是无法访问的，第一是没有内置 CA 证书，另外是 my-nginx 服务开启了 mTLS，需要客户端证书才能访问，现在我们的网格中是没有对应的客户端证书的，会出现 400 错误。开启了双向认证▍为 egress 流量配置双向 TLS创建 Kubernetes Secret 保存客户端证书：kubectl create secret -n istio-system generic client-credential --from-file=tls.key=client.example.com.key \ --from-file=tls.crt=client.example.com.crt --from-file=ca.crt=example.com.crtSecret 所在的命名空间必须与出口网关部署的位置一致，我们这里是 istio-system 命名空间。然后为 my-nginx.mesh-external.svc.cluster.local 创建一个端口为 443 的 Egress Gateway，以及目标规则和虚拟服务来引导流量流经 egress 网关并从 egress 网关流向外部服务。$ kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - my-nginx.mesh-external.svc.cluster.local tls: mode: ISTIO_MUTUAL --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-nginx spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: nginx trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: ISTIO_MUTUAL sni: my-nginx.mesh-external.svc.cluster.local EOF上面我们定义的 Gateway 对象和前面的一样，只是将端口改为了 443，然后在 tls 中指定了 mode: ISTIO_MUTUAL，表示该 Gateway 对象用于 TLS 双向认证协议的请求。然后同样在后面的 DestinationRule 对象中配置了通过 istio-egressgateway 的流量的规则，这里我们定义了 443 端口的 tls 模式为 ISTIO_MUTUAL，表示当访问 my-nginx.mesh-external.svc.clustr.local 的 TLS 请求时执行 TLS 双向认证。最后我们定义一个 VirtualService 对象来引导流量流经 egress 网关：$ kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-nginx-through-egress-gateway spec: hosts: - my-nginx.mesh-external.svc.cluster.local gateways: - istio-egressgateway - mesh # 网格内部的流量 http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: nginx port: number: 443 weight: 100 - match: - gateways: - istio-egressgateway port: 443 route: - destination: host: my-nginx.mesh-external.svc.cluster.local port: number: 443 weight: 100 EOF上面的 VirtualService 对象定义网格内部对 my-nginx.mesh-external.svc.cluster.local 服务的访问引导至 istio-egressgateway，然后再由 istio-egressgateway 引导流量流向外部服务。添加 DestinationRule 执行双向 TLS：$ kubectl apply -n istio-system -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: originate-mtls-for-nginx spec: host: my-nginx.mesh-external.svc.cluster.local trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: MUTUAL credentialName: client-credential # 这必须与之前创建的用于保存客户端证书的 Secret 相匹配 sni: my-nginx.mesh-external.svc.cluster.local EOF发送一个 HTTP 请求至 http://my-nginx.mesh-external.svc.cluster.local：$ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ...检查 istio-egressgateway Pod 日志，有一行与请求相关的日志记录。如果 Istio 部署在命名空间 istio-system 中，打印日志的命令为：kubectl logs -l istio=egressgateway -n istio-system | grep 'my-nginx.mesh-external.svc.cluster.local' | grep HTTP将显示类似如下的一行：[2023-11-17T08:23:51.203Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 17 16 "10.244.1.100" "curl/7.81.0-DEV" "434b5755-54da-9924-9e2a-a204b5a2124c" "my-nginx.mesh-external.svc.cluster.local" "10.244.1.106:443" outbound|443||my-nginx.mesh-external.svc.cluster.local 10.244.2.239:35198 10.244.2.239:8443 10.244.1.100:56448 my-nginx.mesh-external.svc.cluster.local -双向认证即使我们直接在网格中访问的是 HTTP 的服务，但是通过配置 Istio，我们也可以实现对外部服务的双向 TLS 认证。参考文档：https://istio.io/latest/docs/tasks/traffic-management/egress/本文转载自k8s技术圈，原文链接添加社区小助手回复“Istio”进入技术交流群

告警和日志是运维人员快速定位问题、恢复异常的主要手段。运维人员日常的工作模式往往是先接收告警信息，再根据告警信息初步判断异常的范围和影响，通过相关组件的日志定位出故障原因，进行系统恢复。因此，如何给运维人员提供简单易用的告警和日志管理平台是各个云原生平台高度关注的问题。相较传统系统，云原生场景下应用数量非常巨大，监控指标、事件、日志等运维数据更是海量的。同时，告警配置需要联通多个系统，如告警通知人的配置涉及消息通知系统、指标阈值告警规则涉及监控系统、日志关键字告警涉及日志管理系统等。这就导致云原生场景告警的配置复杂度相当高，且涉及跳转到不同系统，流程存在断点。同样，云原生场景下日志文件庞杂繁复。日志有容器标准输出日志、容器内日志、节点日志等多种类型；且日志可能分布在不同的主机上，位置不固定，从而导致日志查找困难。因此，如何帮助运维人员快速精确地查找到故障时间点的完整日志链路并清晰的呈现是日志服务所面临的关键挑战。图1 日志和告警中的挑战针对于上述云原生场景下告警和日志的问题，华为云CCE服务上线告警中心和日志中心功能，实现“一站式告警配置”、“云原生日志视图”。一站式告警配置为了让用户在极短时间内完成系统的基本告警配置，CCE服务联合AOM服务推出云原生专属告警模板，一键即可配置云原生系统的告警规则。此告警模板基于华为云日常运维经验总结提炼，内容涵盖了集群故障事件以及集群、节点、负载资源监控阈值等多方面的常见故障场景。用户只需要在CCE开启告警中心，绑定故障通知人员的邮箱或手机即可。图2 一键开启另外，告警中心还具备告警通知组配置、告警规则配置、告警查看回溯等能力，让运维人员能够一站式完成告警的配置和处理流程，完成闭环。告警中心基于华为云SMN服务提供告警通知组能力。通过配置告警通知组，能够在故障产生时根据问题触发系统的种类和级别及时通知相应的运维人员介入处理。图3 配置告警通知组告警规则可通过告警模板一键下发，涵盖集群常用的指标告警和事件告警。当然，用户也可以自由选配这些告警规则。图4 配置告警规则当告警产生时，告警通知人会及时收到告警通知，并可以通过告警中心提供的可视化界面查看和消除告警。为方便用户对已发生故障进行回溯，告警中心也同样支持查看历史已经消除的告警。图5 告警列表云原生日志视图为了契合云原生业务特征，方便运维人员快速查询日志并准确定位故障，华为云CCE服务推出日志中心功能，提供云原生视角的专属页面版式。图6 日志中心日志中心支持根据K8s资源对象，如工作负载、Pod等进行过滤筛选。同时支持K8s管理日志、审计日志、业务日志等分类展示，整体页面更加简洁，日志主体内容及关联的K8s资源等重点信息更加突出，能够让运维人员聚焦故障点日志，排除干扰。图7 多维度过滤筛选日志中心还提供了日志采集策略的配置管理能力，支持自由配置采集的K8s资源对象。另外，为了进一步降低日志的使用门槛，日志中心提供了控制面日志、审计日志和容器标准输出日志的采集配置模板，支持一键开启或关闭。图8 采集模板本期我们针对告警中心和日志中心的能力给大家进行了简单的介绍。我们非常期待这些能力能够有效地提升您的运维体验。我们将会进行持续优化。期待您的使用以及宝贵的改进意见。服务体验请访问cid:link_3相关链接cid:link_2cid:link_4云容器引擎 CCE

一、MRS流式集群购买按照华为云用户手册（cid:link_0）购买。二、Kafka客户端安装FusionInsight Manager登陆界面下载集群客户端客户端生成成功安装客户端至集群内其他节点解压并校验软件包安装客户端完成三、Kafka消息传递登陆master1节点，并配置环境变量开启IAM用户同步查看并记录一个ZooKeeper角色实例的IP地址创建名为“77”的Kafka topic查看并记录Kafka角色实例中任意一个的IP在topic test中收发消息，内容为姓名全拼（liuchengjie）和学号（201250125）四、Python使用Kafka结果如下，内容为姓名全拼（liuchengjie）和学号（201250125）

作者：华为云云原生团队随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。在过去的很长一段时间内，不同厂商尝试通过扩展单集群的规模来扩展资源池。然而，Kubernetes社区很早就发布了大规模集群的最佳实践，其中包括几项关键数据：节点数不超过5k，Pod数不超过150k，单个节点的Pod数量不超过110 k等。这侧面说明了支持超大规模的集群不是Kubernetes社区主要努力的方向。同时，以单集群的方式扩展资源池通常需要定制Kubernetes的原生组件，这在增加了架构复杂度的同时也带来了不少弊端：（1）集群运维复杂度急剧增加。（2）与社区演进方向相左，后续的维护成本上升，升级路径不清晰。（3）单集群本质上属于单个故障域，集群故障时将导致无法控制爆炸半径。而多集群技术能在不侵入修改Kubernetes单集群的基础上横向扩展资源池的规模，在扩展资源池的同时降低了企业的运维管理等成本。此外，多集群系统天然支持多故障域，符合多数业务场景，如多地数据中心、CDN就近提供服务等。Karmada作为CNCF首个多云容器编排项目，提供了包括Kubernetes原生API支持、多层级高可用部署、多集群故障迁移、多集群应用自动伸缩、多集群服务发现等关键特性，致力于让用户轻松管理无限可伸缩的资源池，为企业提供从单集群到多云架构的平滑演进方案。随着以Karmada为代表的多集群架构在企业的逐步落地，大规模场景下多集群系统的性能问题往往是用户的核心关注点之一。本文将围绕以下几个问题，结合Karmada社区对大规模场景的思考，揭示Karmada稳定支持100个大规模集群、管理超过50万个节点和200万个Pod背后的原理。（1） 如何衡量一个多集群系统资源池的维度与阈值？（2） 对多集群系统进行大规模环境的压测时，我们需要观测哪些指标？（3） Karmada是如何支撑100个大规模K8s集群并纳管海量应用的？（4） 在Karmada的生产落地过程中，有哪些最佳实践和参数优化手段可以参考？▎多集群系统资源池的维度与阈值当前，业界对于多云资源池的Scalability尚未达成统一标准，为此，Karmada社区结合企业用户的实践，率先对这一问题进行了深入探索。一个多集群系统资源池规模不单指集群数量，实际上它包含很多维度的测量标准，在不考虑其他维度的情况下只考虑集群数量是毫无意义的。在若干因素中，社区按照优先级将其描述为以下三个维度：（1） 集群数量。集群数量是衡量一个多集群系统资源池规模和承载能力最直接且最重要的维度。（2） 资源（API对象）数量。对于多集群系统的控制面来说，存储并不是无限的，在控制面创建的资源对象的数量和总体大小受限于系统控制面的存储，也是制约多集群系统资源池规模的重要维度。这里的资源对象不仅指下发到成员集群的资源模板，而且还包括集群的调度策略、多集群服务等资源。（3） 集群规模。集群规模是衡量一个多集群系统资源池规模不可忽视的维度。一方面，集群数量相等的情况下，单个集群的规模越大，整个多集群系统的资源池越大。另一方面，多集群系统的上层能力依赖系统对集群的资源画像，例如在多集群应用的调度过程中，集群资源是不可或缺的一个因素。综上所述，单集群的规模与整个多集群系统息息相关，但单集群的规模同样不是制约多集群系统的限制因素。用户可以通过优化原生的Kubernetes组件的方式来提升单集群的集群规模，达到扩大整个多集群系统的资源池的目的，但这不是衡量多集群系统性能的关注点。在集群的标准配置中，Node与Pod毫无疑问是其中最重要的两个资源，Node是计算、存储等资源的最小载体，而Pod数量则代表着一个集群的应用承载能力。▎大规模场景下多集群系统的性能指标在多集群系统的大规模落地进程中，如何衡量多集群联邦的服务质量是一个不可避免的问题。在参考了Kubernetes社区的SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群系统的落地应用后，Karmada社区定义了以下SLI/SLO来衡量大规模场景下多集群联邦的服务质量。API Call LatencyStatusSLISLOOfficial最近5min的单个Object Mutating API P99 时延除聚合API和CRD外，P99 <= 1sOfficial最近5min的non-streaming read-only P99 API时延除聚合API和CRD外P99 :(a) <= 1s if scope=resource (b) <= 30s otherwise (if scope=namespace or scope=cluster)注：API调用时延仍然是衡量基于Kubernetes的多集群系统服务质量的关键指标。Karmada兼容Kubernetes原生API，用户除了使用原生API创建K8s的资源模板外，也可以使用Karmada自有API来创建多集群策略和访问跨集群的资源。Resource Distribution LatencyStatusSLISLOOfficial用户在联邦控制面提交资源模板和下发策略后到资源在成员集群上被创建的P99时延，不考虑控制面与成员集群之间的网络波动P99 <= 2sCluster Registration LatencyStatusSLISLOWIP集群从接入联邦控制面到状态能被控制面正常收集的P99时延，不考虑控制面与成员集群之间的网络波动TBD注：集群注册时延是从集群注册到控制面到集群在联邦侧可用的时延，它反映了控制面接入集群以及管理集群的生命周期的性能。但它在某种程度上取决于控制面如何收集成员集群的状态。因此，我们不会对这个指标进行强制的限制。Resource UsageStatusSLISLOWIP在接入一定数量的集群后集群联邦维持其正常工作所必需的资源使用量TBD注：资源使用量是多集群系统中非常重要的指标，我们希望在纳管海量的集群和资源的同时消耗尽量少的系统资源。但由于不同的多集群系统提供的上层服务不同，因此对于不同的系统，其对资源的要求也会不同。因此，我们不会对这个指标进行强制的限制。▎Karmada百倍集群规模基础设施揭秘Karmada社区在结合对上述两个问题的思考以及用户在落地过程中的反馈后，测试了Karmada同时管理100个5K节点和2w Pod的Kubernetes集群的场景。本文不详细描述具体的测试环境信息与测试过程，而是侧重于对测试结果进行分析在整个测试过程中，API调用时延均符合上述定义的SLI/SLO。图一：只读API（cluster-scope）调用时延图二：只读API(namespace-scope)调用时延图三：只读API(resource-scope)调用时延图四：Mutating API调用时延Karmada在百倍集群规模下，仍能做到快速的API响应，这取决于Karmada独特的多云控制面架构。事实上，Karmada在架构设计之初就采用了关注点分离的设计理念，使用Kubernetes原生API来表达集群联邦资源模板，使用可复用的策略API来表达多集群的管理策略，同时控制面的资源模板作为应用的模板，不会在控制面生成具体的Pod。不同集群的应用在控制面的映射（Work对象）通过命名空间来进行安全隔离。完整的API工作流如下图所示。如此设计，不仅可以让Karmada能够轻松集成Kubernetes的生态, 同时也大大减少了控制面的资源数量和承载压力。基于此，控制面的资源数量不取决于集群的数量，而是取决于多集群应用的数量。此外，Karmada的架构极具简洁性和扩展性。karmada-apiserver作为控制面的入口与kube-apiserver类似，即使是在百倍集群规模下，Karmada仍能保持快速API响应。Karmada支持通过命令行快速接入集群，以及集群的全生命周期管理。Karmada会实时采集集群心跳和状态，其中集群状态包括集群版本、支持的API列表、集群健康状态以及集群资源使用量等。其中，Karmada会基于集群资源使用量对成员集群进行建模，这样调度器可以更好地为应用选择资源足够的目标集群。在这种情况下，集群注册时延与集群的规模息息相关。下表展示了加入一个5,000节点的集群直至它可用所需的时延。你可以通过关闭集群资源建模来使集群注册时延与集群的大小无关，在这种情况下，集群注册时延这个指标将小于2s。Cluster Registration Latency:metricP50(ms)P90(ms)P99(ms)SLOcluster_register535661256904N/AKarmada支持多模式的集群统一接入，在Push模式下，Karmada控制面直连成员集群的kube-apiserver，而在Pull模式下，Karmada将在成员集群中安装agent组件，并委托任务给它。因此Push模式多用于公有云的K8s集群，需要暴露APIServer在公网中，而Pull模式多用于私有云的K8s集群。下表展示了Karmada在不同模式下下发一个应用到成员集群所需的时延。Resource Distribution Latency:MetricP50(ms)P90(ms)P99(ms)SLOcluster_schedule121532N/Aresource_distribution(Push)70689912982000resource_distribution(Pull)6128819892000结论：我们容易得出，不论是Push模式还是Pull模式，Karmada都能高效地将资源下发到成员集群中。在Karmada演进的数个版本中，大规模场景下使用Karmada管理多云应用的资源消耗一直是用户比较关注的问题。Karmada社区做了许多工作来减少Karmada管理大型集群的资源使用量，比如我们优化了Informer的缓存，剔除了资源无关的节点、Pod元数据；减少了控制器内不必要的类型转换等等。相较于1.2版本，当前Karmada在大规模集群场景下减少了85%的内存消耗和32%的CPU消耗。下图展示了不同模式下Karmada控制面的资源消耗情况。Push模式：Pull模式：总的来说，系统消耗的资源在一个可控制面的范围，其中Pull模式在内存使用上有明显的优势，而在其他资源上相差的不大。▎Karmada大规模环境下的最佳实践Karmada支持性能参数的可配置化，用户可以通过调整组件的参数来调整同一时间段内并发处理Karmada内部对象的数量、系统的吞吐量等以优化性能。同时Karmada在不同模式下的性能瓶颈并不相同，以下着重对此进行分析。在Push模式中，控制面的资源消耗主要集中在karmada-controller-manager（约70%），而Karmada控制面基座（etcd/karmada-apiserver）的压力不大。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较低的水平。在Push模式中，绝大多数的请求来自karmada-controller-manager。因此我们可以通过调整karmada-controller-manager的--concurrent-work-syncs来调整同一时间段并发work的数量来提升应用下发的速度，也可以配置--kube-api-qps和--kube-api-burst这两个参数来控制Karmada控制面的整体流控。在Pull模式中，控制面的资源消耗主要集中在karmada-apiserver，而不是karmada-controller-manager。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较高的水平。在Pull模式中，每个成员集群的karmada-agent需要维持一条与karmada-apiserver通信的长连接。我们很容易得出：在下发应用至所有集群的过程中请求总量是karmada-agent中配置的N倍(N=#Num of clusters)。因此，在大规模Pull模式集群的场景下，Pull模式在资源下发/状态收集方面有更好的性能，但同时需要考虑控制面的抗压能力以及各个karmada-agent和控制面的整体流控。当前，Karmada提供了集群资源模型的能力来基于集群空闲资源做调度决策。在资源建模的过程中，它会收集所有集群的节点与Pod的信息。这在大规模场景下会有一定的内存消耗。如果用户不使用这个能力，用户可以关闭集群资源建模来进一步减少资源消耗。▎总结根据上述测试结果分析，Karmada可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod。在Karmada落地进程中，用户可以根据使用场景选择不同的部署模式，通过参数调优等手段来提升整个多集群系统的性能。受限于测试环境和测试工具，上述测试尚未测试到Karmada多集群系统的上限，同时多集群系统的分析理论以及测试方法仍处于方兴未艾的阶段，下一步我们将继续优化多集群系统的测试工具，系统性地整理测试方法，以覆盖更大的规模和更多的典型场景。添加小助手微信k8s2222，进入云原生交流群

在 KubeCon + CloudNativeCon North America 2022 ，ING集团发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目Volcano如何在数据管理平台中为大数据分析作业提供高性能调度工作。详情参见：KubeCon + CloudNativeCon North America ▎ING背景介绍ING集团（荷兰语：Internationale Nederlanden Groep），亦名荷兰国际集团，是一个国际金融服务私营企业，成立于1991年，由荷兰最大的保险公司Nationale-Nederlanden，与荷兰的第三大银行NMB PostBank Group合并而成。ING集团的服务遍及全球40多个国家，核心业务是银行、保险及资产管理等。ING集团的全球职员大约56,000人，顾客5320万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。务背▎业务背景介绍在银行行业有许多法规和限制，如：监管要求在全球范围内各不相同、数据孤岛-全局和本地限制、数据安全、合规创新等，想要快速引入新技术不是一件容易的事情，为此，ING布局符合自身产业的DAP平台（Data Analytics Platform），为全球50%的ING员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。2013年开始我们有了数据平台的概念，2018年通过引入云原生技术打造新一代基础设施平台，从那时起，平台需求有了稳定的增长，采用率也在持续提升，目前数据索引平台上的项目已超过400个。我们所构建的平台目标是在高度安全的自助服务平台中完成所有分析需求，并且具备以下特点：开源工具模型强大的计算能力严格的安全和合规措施所有的分析集中在同一个平台满足全球和本地需求▎挑战与方案目前我们在由传统的Hadoop平台向Kubernetes过渡，但是对于作业管理和多框架支持方面还存在一些挑战，如下：1.Job的管理a.Pod级调度，无法感知上层应用b.缺乏细粒度的生命周期管理c.缺乏任务依赖关系，作业依赖关系2.调度a.缺少基于作业的调度，如：排序、优先级、抢占、公平调度、资源预定等b.缺少足够的高级调度算法，如：CPU拓扑、任务拓扑、IO-Awareness，回填等c.缺少对作业、队列、命名空间之间资源共享机制的支持3.多框架支持a.对Tensorflow、Pytorch等框架的支持不足b.对每个框架部署（资源规划、共享）等管理比较复杂利用Kubernetes来管理应用服务（无状态应用、甚至是有状态应用）是非常方便的，但是对于批量计算任务的调度管理不如yarn友好，同样yarn也存在一些限制，比如对新框架的支持不够完善，比如TensorFlow、Pytorch等，为此，我们也在寻找新的解决方案。▍Kubernetes + Hadoop在我们之前的集群管理上，会把Hadoop和Kubernetes的调度分开，基本上所有的spark作业都会运行在Hadoop集群中，其他的一些任务和算法会运行在Kubernetes集群，我们的目标是希望所有的任务全部运行在Kubernetes集群，这样管理起来会更简单。Kubernetes和YARN共同工作时，由于Kubernetes和Hadoop资源是静态划分的，在正常办公时间，Hadoop应用和Kubernetes各自使用自身分配资源，即便spark任务压力大也无法借用更多资源。夜晚时间，集群中仅有批处理任务，Kubernetes资源全部空闲，却无法分配给Hadoop进行有效利用，对于调度平台来讲，这不是一种最佳的资源分配方式。▍Kubernetes with Volcano使用Kubernetes管理整个集群，通过Volcano进行spark任务调度，此时不需要再对资源做静态划分，集群资源可根据Pod、Batch、Interactive任务的优先级、资源压力等进行动态调整，集群整体资源利用率得到极大提升。比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch和Interactive应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch和Interactive应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。Volcano是专为Kubernetes而生的批处理调度引擎，其提供了以下能力：加权优先级的作业队列如果集群具有备用容量，可提交超过队列资源限制的任务当更多的pod被调度时，具备抢占能力丰富可配置的工作负载调度策略     5.兼容YARN的调度能力Volcano的引入，补齐了Kubernetes平台对批处理作业的调度管理能力，并且自Apache Spark 3.3版本以来，Volcano被作为Spark on Kubernetes的默认batch调度器，安装使用更方便。业务常用特性▍冗余与局部亲和Volcano保留Kubernetes中pod级别的亲和性反亲和性策略配置，并增加了task级别的亲和性和反亲和性策略。▍DRF（Dominant Resource Fairness）调度DRF调度算法的全称是Dominant Resource Fairness，是基于容器组Domaint Resource的调度算法。volcano-scheduler观察每个Job请求的主导资源，并将其作为对集群资源使用的一种度量，根据Job的主导资源，计算Job的share值，在调度的过程中，具有较低share值的Job将具有更高的调度优先级。比如集群资源总量为CPU：18C，Memory：72GB，两个用户分别是User1和User2，每个User分配1个队列，在提交作业时会根据主导资源计算job的调度优先级。User1: CPU share值为 6/18=0.33，Memory share值为 24 / 72 = 0.33，最终share值为0.33User2：CPU share值为 12/18=0.67，Memory share值为 24 / 72 = 0.33，最终share值为0.67DRF策略在任务调度时，优先分配share值较低的Job，即User1所申请的资源。集群内队列资源可以通过配置权重值进行划分，但是当本队列提交任务超出队列分配的资源，并且其他队列存在资源空闲时，可以进行队列间资源共享。即User2在使用完本队列CPU资源后，可以使用User1队列内的空闲CPU资源。当User1队列提交新任务需要CPU资源时，将会触发抢占动作，回收User1被其他队列借用的资源。▍避免资源匮乏在使用过程中，需要避免批量计算任务与自有服务出现资源抢占与冲突的问题。比如：我们集群中有两个可用节点，集群中需要部署一个统一的服务层对外提供服务，比如Presto，或者类似Alluxio的缓存服务。但是在批量计算调度时，集群的资源空间有可能全部被占用，我们将无法完成自有服务的部署或升级，为此我们增加了空间可用系数相关配置，为集群预留一些备用空间，用于自有服务的部署使用。▍DRF 仪表盘我们根据Volcano的监控数据做了一个drf调度的仪表盘，在不同层次显示更细粒度的调度信息。在业务集群中，我们有一个队列存放交互式用户的任务，另有队列存放平台运行的所有重大项目的计算任务，我们可以为重大项目队列提供一定的资源倾斜，但是此时对交互式用户的任务将不会太友好。目前我们正在考虑增加集群高峰时段展示的功能，为用户提供更多的集群使用状态和压力等信息，在自助服务平台用户视角来看，用户按照集群的繁忙程度选择自己任务的开始时间，这样可以避免后台复杂的配置就可以获得高性能的运算体验。总结Volcano对批处理任务调度做了很好的抽象，使我们在Kubernetes平台能够获得更高的调度性能，后面我们也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的Prometheus监控指标、Grafana仪表盘更新、kube-state-metrics更新和集群角色限制等。Volcano社区技术交流地址Volcano官网：https://volcano.shGitHub : cid:link_0每周例会： https://zoom.us/j/91804791393添加社区小助手k8s2222回复“Volcano”进入技术交流群

2023年4月8日，Kurator正式发布v0.3.0版本。Kurator 是华为云推出的分布式云原生开源套件，通过集成业界主流开源技术栈，帮助用户一站式构建专属的分布式云原生基础设施，助力企业业务跨云跨边、分布式化升级。Kurator v0.2 版本已具备管理多云基础设施和异构基础设施的核心能力，通过引入Cluster Operator组件，支持“AWS自建集群”和“本地数据中心集群”包括集群创建、清理等在内的生命周期管理特性。在最新发布的v0.3.0版本中，Cluster Operator不仅分别对两类集群的生命周期管理能力进行了增强，也将v0.2.0版本中的多个API对象抽象成一个API对象cluster，方便用户使用。 同时，在 cluster 对象基础上，Kurator引入了舰队的概念。每个舰队代表一个物理集群组，方便Kurator未来进行统一的编排、调度，统一的流量治理以及统一的监控运维。目前，Kurator的舰队管理支持多个特性，包括舰队控制平面的生命周期管理，以及集群注册和注销到舰队等。至此，Kurator 通过集群舰队统一了集群视图。这意味着，Kurator开始具备了支持用户体验一致地管理分布在任何云上的集群的能力，从而进一步协助用户的分布式云原生架构的升级。Kurator v0.3.0关键特性介绍集群生命周期管理能力增强Kurator 通过 Cluster Operator组件对集群的生命周期进行管理。基于Cluster API，Cluster Operator 不仅可以管理集群生命周期，还统一并简化了创建集群所需的配置，为用户在不同云平台上管理集群提供了简单易用的API。目前Cluster Operator 支持“本地数据中心集群”和“AWS自建集群”。本地数据中心集群Kurator基于kubespray对本地数据中心集群的生命周期进行管理。与 kubespray不同的地方在于，Kurator采用了更易于理解和配置的云原生声明式的方法管理集群。相比较v0.2.0版本，v0.3.0版本的Kurator 带来了以下几个方面的增强特性：• 批量的工作节点扩缩容。 现在Kurator支持以声明式的方式，在原有集群上增加、删除或者替换多个工作节点。 用户只需要声明集群所需要的最终工作节点状态，Kurator即可在没有任何外部干预的情况下完成节点的批量扩缩容。• 集群版本升级。 用户可以在API对象上声明要升级到的Kubernetes版本，Kurator便会自动对目标集群的各节点进行升级。• 增强集群控制面高可用。Kurator为用户提供了一种基于VIP的增强集群控制面高可用的方案。在这种方案下，Kurator利用kube-vip的能力，使用VIP实现跨多个控制平面副本的入站流量负载均衡。图片来源：https://inductor.medium.com/say-good-bye-to-haproxy-and-keepalived-with-kube-vip-on-your-ha-k8s-control-plane-bb7237eca9fc用户手册：https://kurator.dev/docs/cluster-operator/vms-cluster-lifecycle/AWS自建集群Kurator 通过Cluster Operator对AWS自建集群进行生命周期管理管理。相较于Cluster API 对AWS 自建集群的支持， Kurator简化了Cluster API提供的部署模型，通过部署Kurator集群操作器组件即可获得全部的管理能力。v0.3.0在以下几个方面带来了特性增强：• 易用性提升。kurator新增了一系列提升用户体验的改进, 包括了在创建集群之前验证凭据是否有效，自动管理云平台运营商所需的IAM角色和策略，校验依赖资源是否存在以及集中展示错误信息等。一键关联IAM与K8s身份。通过将AWS IAM角色与Kubernetes Pod身份关联，可以让IAM验证和接受Kubernetes颁发的令牌，而不需要创建和分发AWS凭据。这种关联具有最小特权、凭证隔离和审计性等优点，但是需要通过多个步骤设置。Kurator现在可以通过Cluster.Spec.PodIdentityg一键启用该功能，简化配置。apiVersion: cluster.kurator.dev/v1alpha1 kind: Cluster metadata: name: pod-identity namespace: default spec: ... podIdentity: enabled: true用户手册：https://kurator.dev/docs/cluster-operator/kurator-cluster-api/https://kurator.dev/docs/cluster-operator/aws-irsa/云原生舰队管理Kurator引入了代表物理集群组的逻辑单元“舰队”，旨在一致地管理一组集群，舰队允许您轻松、一致地管理分布在任何云中的集群。Kurator通过Fleet Manager实现了对舰队控制平面生命周期管理，并且可以轻松的将集群添加到或从舰队中删除。 未来，Kurator将支持Fleet级的应用编排，并且在Fleet的所有集群中提供统一的命名空间、ServiceAccount、Service，以支持在多个集群之间实现服务发现和通信。此外，Kurator将汇总来自所有集群的监控指标。Kurator Fleet Manager作为一个Kubernetes Operator运行，负责Fleet控制平面生命周期管理，也负责集群的注册和注销。用户手册：https://kurator.dev/docs/fleet-manager/Kurator，一键构建分布式云原生平台访问Kurator Release（cid:link_0），体验、升级最新版Kurator v.0.3.0，构建您的专属分布式云原生平台。如您对Kurator新版本特性有更多兴趣或见解，也欢迎来到Kurator社区，参与社区讨论与开发。GitHub地址：cid:link_1Slack地址：https://join.slack.com/t/kurator-hq/shared_invite/zt-1sowqzfnl-Vu1AhxgAjSr1XnaFoogq0A

作者：华为云云原生团队Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。本版本其他新增特性：提供了多调度器支持能力，默认调度器可以与第三方自定义调度器协同工作，提供更强的定制能力。集群差异化配置策略（OverridePolicy/ClusterOverridePolicy）将按照隐式的优先级进行应用。内置资源解释器支持聚合StatefulSet/CronJob 状态。新特性概览多调度组根据 Flexera 发布的《2023 年云现状调查报告》，云成本的管理取代了安全性话题，成为当下云使用者面临的首要问题。Karmada 秉承这一趋势，同样关注云成本管理。从v1.5版本开始，用户可以在 PropagationPolicy/ClusterPropagationPolicy 中设置多个集群组，实现将业务优先调度到成本更低的集群组。下面我们给出一个针对成本优化进行调度的例子：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: local-clusters clusterNames: - local-member1 - local-member2 - affinityName: cloud-clusters clusterNames: - huawei-member1 - huawei-member2上面的例子配置有本地集群组（local-clusters）和云上集群组（cloud-clusters），Karmada 在选择集群组进行资源分发时， 将按顺序对集群组逐一进行评估，直到找到满足调度约束的集群组。所以在调度Deployment/nginx时，会优先尝试调度到本地集群组的local-member1和local-member2，如果失败（如资源不足），则选择云上集群组，从而实现在本地集群资源足够时，优先选择成本更低的本地集群。基于此，系统管理员也可以定义主集群组和备份集群组，在主集群组故障时，将业务往备份集群组的集群迁移。下面我们给出一个针对容灾迁移的例子：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: primary-cluster clusterNames: - member1 - affinityName: backup-cluster clusterNames: - member2上面的例子通过配置主群组（primary-cluster）和备份集群组（backup-cluster），在调度 Deployment/nginx 时，如果主集群组满足要求，会调度到主集群组的member1。在主集群组的集群故障时，调度器按顺序匹配新集群组，将业务迁移到备份集群组的member2。关于多调度组更多信息，请参考：cid:link_0自定义调度器Karmada 默认调度器内置多款可灵活配置的插件，可以满足大部分使用场景，用户还可以使用插件扩展机制来实现个性化调度诉求。Karmada 1.5版本提供了多调度器支持能力，Karmada 默认调度器可以与第三方自定义调度器协同工作，以提供更强的定制能力。用户可以参考默认调度器实现自定义调度器，当多个调度器共存时，需通过命令行启动参数指定调度器名称，如 --scheduler-name=my-scheduler 。如果自定义调度器与默认调度器部署在同一namespace中，建议同时配置 --leader-elect-resource-name 参数，以避免副本选主冲突。关键命令行启动参数如下所示：command: - /bin/karmada-scheduler - --kubeconfig=/etc/kubeconfig - --bind-address=0.0.0.0 - --secure-port=10351 - --enable-scheduler-estimator=true - --leader-elect-resource-name=my-scheduler # 你的自定义调度器名称 - --scheduler-name=my-scheduler # 你的自定义调度器名通过参数 --scheduler-name 将多个调度器进行区分，每个调度器将只负责调度特定的工作负载。通过 Karmada 分发工作负载时，可以在 PropagationPolicy/ClusterPropagationPolicy 的 schedulerName 字段指定调度器名字，如下所示：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: schedulerName: my-scheduler resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2上例通过 schedulerName 指定此Deployment必须由名为 my-scheduler 的调度器进行调度，此时默认调度器将自动忽略该工作负载。schedulerName 如果没有指定，则默认值为 default-scheduler ，意味着由默认调度器进行调度，前面版本的用户升级到新版本时无需额外配置。关于如何扩展调度器插件和实现自定义调度器，请查看官方文档：cid:link_1版本升级Karmada v1.5版本API兼容v1.4版本API，v1.4版本的用户仍然可以平滑升级到v1.5版本。可参考升级文档：https://karmada.io/docs/administrator/upgrading/v1.4-v1.5致谢贡献者Karmada v1.5版本包含了来自25位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID:@a7i@calvin0327@carlory@chaunceyjiang@fengshunli@Fish-pro@Garrybest@helen-frank@ikaven1024@jwcesign@lonelyCZ@maoyangLiu@my-git9@Poor12@qingwave@RainbowMango@VedRatan@Wang-Kai@whitewindmills@wlp1153468871@wongearl@XiShanYongYe-Chang@yanfeng1992@yanggangtony@Zhuzhenghao参考链接Release Notes：cid:link_2多调度组：cid:link_02023 年云现状调查报告：cid:link_3扩展调度器插件和实现自定义调度器：cid:link_1附：Karmada社区技术交流地址项目地址：cid:link_4Slack地址：https://slack.cncf.io/(#karmada)

作者：华为云云原生团队Gateway API是一个开源的API标准，源自Kubernetes SIG-NETWORK兴趣组。从出身角度讲，可谓根正苗红，自从开源以来备受关注，被寄予厚望。Gateway API旨在通过声明式、可扩展性和面向角色的接口来发展Kubernetes服务网络，并且希望成为供应商的网关API标准并获得广泛行业支持。简而言之，Gateway API希望取代Ingress API。Gateway API 项目自2019年开源，但是经历了缓慢的发展，直到2022年7月才发布Beta版本，同时发起了GAMMA（Gateway API for Mesh Management and Administration）。笔者认为这里主要有两方面的原因：- Ingress存在已久，并且是几乎所有的Ingress Controller的默认实现，Kubernetes的用户早已习惯Ingress，尽管Ingress在易用性和功能丰富度上面存在很大的差距。- 服务网格或者API网关项目，例如Istio、Linkerd、Kong、Contour、Ambassador等都有自己的API标准，Gateway API用户接受度还不够高。- 由于Gateway API并没有强大的用户基础，因而缺少功能、体验上的反馈，因而迭代比较缓慢。▍ 什么是GAMMAGAMMA (Gateway API for Mesh Management and Administration)是Gateway API项目的一个工作组。该小组的目标是调查、设计和跟踪网关API资源、语义，并负责其他与服务网格技术和用户使用场景相关的工件。此外，GAMMA倡导服务网格项目的网关API实现之间的一致性，无论Istio还是Linkerd，大家最好都来遵守这里定义的API规范和标准。GAMMA的Lead团队由来自Google的John Howard（Istio），来自微软的Keith Mattix（Open Service Mesh）和来自HashiCorp的Mike Morris（Consul）组成，在不同组织和服务网格项目的推动下，Gateway API有望统一服务网格API。▍ 推波助澜KubeCon EU 2022上，Envoy Gateway的指导组，包括Envoy创始人Matt Klein，以及来自Ambassador、Fidelity 、Tetrate和VMware的代表共同宣布将开源Envoy Gateway项目，将Envoy用作“开箱即用”的基本API网关和Kubernetes Ingress控制器。通过实现Kubernetes Gateway API， EG将会使Envoy扩展更加容易。Envoy上游开源一个网关项目，并且EG是站在Ambassador以及Contour等项目的肩膀上前进，给普通开发者带来无限的遐想。最重要的是，EG是第一个主要实现Gateway API的项目，这一操作也为Gateway API带来新的活力，直接推动Gateway API在7月份发布了Beta版本。  Gateway API 生态 前面提到Envoy Gateway项目宣布以Gateway API为唯一的网关标准，并且EG也是唯一一个只遵守Gateway API标准的Ingress网关项目。其他实现者，都是在自身API的基础上，额外支持Gateway API。并且对Gateway API的支持普遍比较初级：项目名称                    主流支持 Gateway API支持程度Apache APISIXNalphaCiliumNWIPContour NalphaEmissary-Ingress (Ambassador API Gateway)NalphaGloo Edge 2.0NWIPGKE   N公开预览HAProxy IngressNalphaConsul  NalphaIstio NalphaKong  NalphaKuma   NalphaNGINX Kubernetes GatewayNpre-alphaTraefik Nalpha**Envoy Gateway****Y**pre-alphaGateway API绝不仅仅关注南北向流量治理策略的标准，东西向流量也是它所重点覆盖的方向。南北向主要是一些网关项目的领地，东西向是服务网格的领地。当然服务网格如Istio都有自己的Ingress Gateway, 能够对北向流量进行管理。东西向流量从特征上要比南北向流量更多，因为客户端在集群中，可以通过Labels标签表示客户端的属性，通过ServiceAccount标识身份。网格在东西向流量治理时能够充分利用K8s工作负载的标签、身份进行更多的路由、安全策略控制。Gateway API标准在东西向流量这一块目前并没有对等服务网格现有的能力，具体在最后一章再来进行对比。前期Gateway API主要关注的还是南北向的流量治理标准，这与它 “取代Ingress” 的设计初衷相符。  Gatewy AP设计    Gateway API设计 Gateway API基于可移植、可扩展、表达性强以及面向不同角色四个原则设计。- 可移植：相对Ingress来说这一点并不是改进，而是保持与Ingress一致，通过通用的规范，能让更多的网关轻松实现。而Gateway API所追求的领域绝不仅限于南北向网关，而且它还要覆盖服务网格。- 表达性强：Gateway API支持核心功能，如基于Header匹配、流量权重分隔以及其他功能，这些功能只有在Ingress中通过自定义注释Annotation才能实现。- 可扩展：Gateway API允许引用其他的自定义资源对象，这使得在API结构中的适当位置进行个性化定制成为可能。- 面向角色：从上图可见Gateway 由不同的API资源构成，分别为不同的角色设计。其中应用开发者定义HTTPRoute，集群维护者定义Gateway对象，基础设施提供者定义GatewayClass。本章选取面向角色和可扩展性两个最具代表性的设计原则，详细解释Gateway API的设计。▍ 面向角色的API设计无论是道路、电力、数据中心还是Kubernetes集群，基础设施都是为共享而构建的。然而，共享基础架构提出了一个共同的挑战--如何为基础架构的用户提供足够的灵活性，同时保持基础架构所有者的独立控制？Gateway API通过面向角色的设计为K8s服务网络提供灵活的控制，该设计在分布式灵活性和集中控制之间取得了平衡。它允许许多不同的团队使用共享网络基础架构（硬件负载平衡器、云网络、网关等），所有这些团队都受集群维护者设置的策略限制和约束。如下是Gateway API官网的实例，集群维护者通过Gateway定义流量入口，以及TLS Terminate。集群中有两个租户，其中存储开发者在Store命名空间部署了自己的微服务，站点开发者在Site命名空间也部署了自己的微服务。他们在集群网关上共用同一域名，同一端口，因此网关只能通过匹配不同的HTTP Authority来路由客户端的请求。路由策略的设置则是由应用开发者们（Store、Site开发者）自己定义，然后绑定到同一个Gateway上。下面通过一个官方示例，为大家展示不同的角色如何根据自己的权限来定义服务的治理策略。集群维护者通过Gateway定义Listener以及允许绑定的路由策略。如下 *shared-gateway*表示在443端口监听连接，通过 *foo-example-com*证书在网关处做TLS终结。```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: shared-gateway namespace: infra-ns spec: gatewayClassName: shared-gateway-class listeners: - name: https hostname: "foo.example.com" protocol: HTTPS port: 443 allowedRoutes: namespaces: from: Selector selector: matchLabels: shared-gateway-access: "true" tls: certificateRefs: - name: foo-example-com ```集群维护者定义只允许以下命名空间的路由策略能够绑定网关，因为它们有shared-gateway-access: "true"标签。```yaml apiVersion: v1 kind: Namespace metadata: name: infra-ns labels: shared-gateway-access: "true" --- apiVersion: v1 kind: Namespace metadata: name: site-ns labels: shared-gateway-access: "true" --- apiVersion: v1 kind: Namespace metadata: name: store-ns labels: shared-gateway-access: "true" ```这里可以看出，不同角色权限控制比较严格，只有集群维护者允许的路由策略才能绑定到网关上。应用开发者，只能对所拥有的服务具有控制权。▍ 可扩展性-Policy挂载策略挂载提供了高扩展性，虽然超时，重试，以及个性化的健康检查在一些网关实现中很常见，但是大多数网关的实现方式是不同的，没有统一的API标准。保持这类API的一致性变得艰难，所以Gateway API特意设计了Policy挂载，允许在网关、路由中插入个性化的策略控制。  Ingress策略挂载Mesh策略挂载从上图可以看到，无论是Gateway还是HTTPRoute都允许任意引用其他的策略，此设计大大提高了Gateway API的扩展能力。  Gateway API还有多远 Gateway API与其他主流API对比从上述功能丰富度对比来看，Istio API > Gateway API > Ingress, 然而Gateway API通过Reference其他自定义对象提供的扩展能力明显强于Istio。尽管当前Gateway API没有提供故障注入，超时、重试，限流等策略，但是通过它超强的扩展能力能够很容易做到。阅读本文，大家对Gateway API一定充满了好奇，Gateway API距离成熟、大规模商用还有多远？首先从目前的生态分析，Gateway API被Kubernetes圈普遍认可，包括开源项目、甚至商业服务GKE的支持。归根到底，Gateway API由Kubernetes网络组发起、维护，并且吸引了大量开源网络项目的维护者参与。当然实际背后控制者是Google，Google在开源技术的领导力毋庸置疑。但是不得不认识到，目前所有Gateway API的支持都处于初级阶段。其次，从兼容性的角度看，一些成熟的项目，比如Istio，用户长期以来习惯了Istio的API标准，Istio社区也不会贸然的废弃原有的API，转而只支持Gateway API。因此这种多种API并存的局面将会持续很久，即使在未来Gateway API成熟了。最后，前面讲到Gateway API对超时、重试、故障注入等能力预留了扩展能力，但是这种基本的网络能力，Gateway API应该提供标准的API，而不是让用户自己去定义私有的标准。这也违背了Gateway API想要统一服务网络标准的初衷。除此之外，灵活的扩展性如果违背了易用性，显然用户是不会买账的。综上所述，笔者认为至少在一两年之内，Gateway API将会持续迭代，短时间内很难形成成熟的标准。或许可以期待，2024年以后服务网格和API网关的标准将会统一。参考文献1. Kubernetes gateway API官网：https://gateway-api.sigs.k8s.io/2. https://blog.envoyproxy.io/introducing-envoy-gateway-ad385cc595323. Istio官网：https://istio.io/3. Nginx Ingress Controller: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/技术干货 | 活动报名 | 大咖交流，添加小助手微信k8s2222

作者：华为云云原生团队如果说在以Kubernetes为基础构建起的云原生世界里，哪种设计模式最为经典，Sidecar模式无疑是其中最有力的竞争者。当需要为应用提供与自身逻辑无关的辅助功能时，在应用Pod内注入对应功能的Sidecar显然是最Kubernetes Native的方式，而Istio则是这种模式的代表。Istio项目的愿景是以尽量透明的方式，解决微服务场景下，服务间的连接、安全以及可观测性问题。主要实现手段则是通过在应用旁部署一个Proxy，在Kubernetes场景下则为应用Pod注入Sidecar，拦截应用流量至Sidecar。Sidecar根据从Istio控制面获取的用户配置对应用流量进行处理，以一种对应用代码几乎无侵入的方式实现了服务治理。图1虽然Istio并不局限于仅支持Kubernetes平台，但是Istio的设计理念与Kubernetes的Sidecar模式有着天然的亲和性。基于Sidecar模式，Istio能够实现在Kubernetes平台上的快速开发、部署、验证。同时，在功能层面，Isito将服务治理功能从应用代码中剥离，作为基础设施下沉至Sidecar，抽象出了事实上的云原生应用网络层，极大地减轻了应用开发者的心智负担，这部分能力刚好也是Kubernetes生态一直以来缺失的。基于Istio对于Kubernetes生态的完美补充，随着Kubernetes的大规模普及，Istio也实现了对用户心智以及市场的快速抢占。虽然以Sidecar模式部署Istio数据面似乎是一个理所应当，让人无法拒绝的选择，但是需要强调的是，Istio完整功能的实现并不与Sidecar模式强绑定，我们还有各种各样其他的选择。另外，随着对于Istio使用程度不断加深，落地规模不断扩大，可以发现以Sidecar模式部署Istio数据面诸多挑战：1. 侵入性：Istio基本实现了对应用代码的零侵入，但是由于Sidecar的注入需要更改Pod Spec并且对应用流量进行重定向，因此应用接入网格时需要重启Pod，而应用容器与Sidecar容器的启动顺序不确定造成的冲突也可能导致应用中断；2. 生命周期绑定： Sidecar本质上是基础设施，它和应用的生命周期往往不一致，因此升级Sidecar时也需要对应用Pod进行重启，同样可能导致应用中断，而对于Job类应用，Sidecar的存在则会导致Pod无法被及时清理；3. 资源利用率低：Sidecar为单个应用Pod独占，应用的流量存在波峰波谷，而一般情况下Sidecar的内存占用与集群规模（Service数目，Pod数目）强相关，因此需要按照极端情况预留资源，导致集群整体的资源利用率低。同时由于需要为每个Pod注入Sidecar，随着集群规模的不断扩大，Sidecar占用的资源总量也会线性上涨。针对Sidecar部署模式的缺陷，Google和Solo.io联合推出了一种新的Sidecar-less部署模式 --- Ambient Mesh。架构介绍图2Ambient Mesh架构如上图所示，从设计的角度来看，它主要有以下两个特点：1. Sidecar-less：为了避免上述Sidecar模式的种种缺陷，Ambient Mesh不再为任何Pod注入Sidecar，将网格功能的实现进一步下沉到Istio自有组件中。2. L4/L7处理分层：Ambient Mesh引入了ztunnel和waypoint两个组件用于代替原来的Sidecar实现相关功能，与Sidecar既能处理L4，又能处理L7流量的实现方式不同，Ambient Mesh对两者进行了区分，ztunnel只负责L4流量的处理，L7的流量则按需交由waypoint处理。Ambient Mesh的控制面与原先Sidecar模式的Istio相比基本没有变化，数据面的组件构成以及各个组件的作用如下：1. istio-cni：必装组件，以DaemonSet的形式部署。其实istio-cni并不是Ambient Mesh的新增组件，在原先的Sidecar模式中就已经存在，当时主要用于替代istio-init这个Init Container配置流量拦截规则，同时规避istio-init引发的安全问题。Ambient Mesh对它进行了扩展，以必装组件的形式部署，负责配置流量转发规则，劫持本节点中已加入Ambient Mesh的Pods的应用流量，转发至本节点的ztunnel；2. ztunnel: 必装组件，以DaemonSet的形式部署。ztunnel对所在节点Pods的流量进行代理，主要负责L4流量的处理、L4的遥测以及服务间mTLS（双向认证）的管理。最初ztunnel基于Envoy实现，但是考虑到对ztunnel功能的有意约束以及对安全性、资源占用率的要求，社区已经用rust从零构建该组件；3. waypoint：按需配置，以Deployment的形式部署。waypoint负责处理HTTP，故障注入等L7功能。以负载或者Namespace粒度进行部署，在Kubernetes中，即一个Service Account或者一个Namespace对应生成一个waypoint的Deployment，用于处理发往对应负载的七层流量，同时waypoint实例数可以根据流量动态伸缩。图3下面以Ambient Mesh数据面实际的处理过程来展示上述各个组件在其中扮演的具体角色：1. 与Sidecar模式类似，Ambient Mesh也能以网格、Namespace以及Pod的粒度将服务加入网格；不同的是，新加入的Pod无需重启，更不需要注入Sidecar；2. istio-cni监听本节点内Pods的增删以及进出网格的情况，动态调整转发规则，网格内Pods发出的流量会被透明地转发至本节点的ztunnel，直接跳过kube-proxy的处理；3. ztunnel同样需要对本节点Pods的增删以及进出网格的情况进行监听，从控制面获取位于本节点且被网格接管的Pods的证书并进行管理；4. 源端ztunnel对拦截的流量进行处理，根据流量的源IP找到对应Pod的证书，由此和对端建立mTLS；5. 如果要访问的目标服务没有配置waypoint或者没有配置L7相关的处理策略，则源端ztunnel直接和目的端ztunnel建立连接（如上图黄线标注），对端的ztunnel终止mTLS，执行L4安全策略，将流量转发到目标Pod；6. 如果目标服务配置了waypoint（利用特殊配置的Gateway对象）以及L7的处理策略，则源端ztunnel会和对应的waypoint建立mTLS，waypoint终止mTLS后，进行L7的逻辑处理，之后再与目标Pod所在节点的ztunnel建立mTLS，最终同样由目的端的ztunnel终止mTLS并将流量发往目标Pod。▎价值分析虽然从底层实现来看，Ambient Mesh和原有的Sidecar模式的差别巨大，但是从用户面看，两者在核心Istio API（VirtualService, DestinationRules等）的使用方式、实现效果都是一致的，能够确保基本相同的用户体验。Ambient Mesh是Istio社区除Sidecar模式外，支持的第二种数据面模式，所以网格技术本身能为用户带来的价值，Ambient Mesh与先前的Sidecar模式并不二致。因此这里只对Ambient Mesh相对于原生Sidecar模式的价值进行分析，对于网格本身的价值不再赘述。Ambient Mesh主要是针对Istio的数据面架构进行调整，用于克服既有Sidecar模式的不足，因此它的价值产生必然是基于其架构特点。前文已经提到过Ambient Mesh的架构特点主要有“Sidecar-less”和“L4/L7处理分层”这两点，下面就从这两点出发进行价值分析：1. Sidecar-less的优势，其实可以看作Sidecar模式缺陷的对立面：a) 透明：网格功能下沉至基础设施，不仅对应用代码零侵入，和应用的生命周期也完全解耦，做到真正对应用透明，允许应用与网格独立演进；b) 优化资源占用：数据面占用的CPU、内存等资源不再随着实例数线性增长，随着数据面的实例数减少，与控制面的连接数也相应减少，极大地减轻控制面的资源与处理压力。2. 对于为什么要对L4/L7进行分层处理，首先要区分两者之间的区别。与L4相比，L7的处理更为复杂，需要占用更多的CPU/内存等资源，不同类型的操作之间资源占用也存在较大差别；同时操作越复杂暴露的攻击面越大。另外Envoy当前并不支持对不同租户的流量进行强隔离，“Noisy Neighbor”的问题不可避免。因此Ambient Mesh分层处理架构的优势如下：a) 资源利用率高：ztunnel仅负责L4的处理，L4处理较为简单且资源占用较为固定，所以更易对ztunnel进行资源规划，无需过量预留资源，能够将更多的节点资源供用户使用；waypoint更可以根据L7负载动态扩缩容，充分利用集群中的资源碎片；b) 租户隔离：处理复杂、安全风险高的L7处理由租户（Service Account）各自的waypoint处理，既避免了租户间的资源抢占，又限制了安全问题的爆炸半径；c) 平滑落地：允许用户逐步接入网格，当仅需网格的L4处理能力时，完全无需考虑L7的资源占用以及可能造成的潜在负面影响（例如：因为错误配置导致进入L7处理而应用并未完全遵守L7协议，导致服务中断），之后在适当时刻按需开启相关功能即可。当然Ambient Mesh作为Istio全新的数据面架构，在社区中依然以实验特性的形式存在，仍然有许多问题亟待解决，例如：1. 性能：尤其是针对L7的处理，Ambient Mesh需要经过两个ztunnel以及一个waypoint，肉眼可见地又额外增加了一跳，因此完整的L7处理需要额外经过三跳。虽然社区声称这对性能的影响很小，但是仍需待其特性稳定后进一步观察对比；2. 容器网络适配：虽然Ambient Mesh与应用基本实现了完全解耦，但是反过来也增加了网格与底层基础设施的耦合，Sidecar模式仅需在Pod的net ns实现流量的拦截处理，但是Ambient Mesh在主机网络进行流量拦截，显然需要更多考虑与底层容器网络的适配；3. 配置复杂：原本Envoy复杂的配置就被广为诟病而Ambient Mesh更需要实现一个ztunnel对节点所有Pods的代理，配置复杂度更是上升一个数量级，同时配置的复杂意味着处理流程的增加，也会对数据面的排错以及整体性能造成影响；4. 其他：ztunnel的高可用？waypoint事实上将原本双端的L7处理变为了单端，对L7监控指标正确性的影响？…▎未来展望从版本发布的角度，自从2022年9月份发布以来，Ambient Mesh一直作为实验特性存在于独立的分支之中。因此对于Ambient Mesh下一步的计划就是合入主干分支（已于2023年2月实现）并作为Alpha特性发布，最终在2023年底到达Stable，实现生产可用。从API的角度，最理想的是能在两种架构下共用同一套API。当然这是不现实的，因为已有的一部分Istio API是以Sidecar模式部署为前提条件设计的。最典型的就是Sidecar这个CRD，它用于定制化下发至不同Sidecar的配置，从而减少Sidecar不必要的资源占用。这些Sidecar-Only的API显然在Ambient Mesh下毫无意义。同时，Ambient Mesh自身也引入了ztunnel和waypoint两个独有组件，因此Ambient Mesh也需要创建新的API，用于管理这些独有组件以及实现一些Ambient Mesh Only的功能。最终Ambient Mesh会实现已有的核心Istio API（VirtualService, DestinationRules等）并创建一些其独有的API，重要的是做到三类API（Sidecar模式独有、Ambient Mesh独有、两者共有）统一的使用与交互。那么Ambient Mesh是否做到了对Sidecar模式使用场景的全覆盖，从而让Sidecar模式彻底退出历史舞台了呢？答案自然是否定的，类似于业界各种独占模式和共享模式之争，Sidecar模式本质上是应用Pod对Proxy的独占。专属的Proxy往往能保证更好的资源可用性，尽量避免其他应用的影响，确保高优先级应用的正常运行。可以预见，最终两种模式的混合部署，应用按需选择代理模式是更为理想的方式。所以构建混合部署模式，保证该模式下两种模式的良好兼容性和统一的体验也将是后续工作的重点。▎总结Sidecar模式对于Istio就像一场原型验证，以一种最Kubernetes Native的方式快速展示网格技术的价值，抢占用户认知和市场。不过随着Istio的落地逐渐进入深水区，开始在生产环境大规模部署，Sidecar模式就显得力不从心了。此时Ambient Mesh以一种更符合大规模落地要求的形态出现，克服了大多数Sidecar模式的固有缺陷，让用户无需再感知网格相关组件，真正将网格下沉为基础设施。但是显然Ambient Mesh并不是网格数据面架构演进的终点。当前还没有一种网格数据面方案能在侵入性、性能、资源占用等各个考量维度做到完美。Ambient Mesh基本做到了对应用的零侵入，但是L7的三跳处理引发的性能问题，ztunnel等常驻进程的资源占用令人无法忽视；gRPC等RPC库通过内置实现xDS，直连Istio控制面，将网格杂糅进SDK，确实能实现很好的性能和资源占用表现，只是不可避免地需要付出与应用强耦合、多语言支持复杂度高等固有代价；基于eBPF直接将全套网格数据面功能像TCP/IP协议栈一样下沉到内核貌似是理想的终局方案，只是考虑到内核安全以及与内核交互的复杂性，eBPF的执行环境其实是非常受限的，例如eBPF程序加载到内核前必须经过verifier的校验，执行路径必须完全已知，无法执行任意的循环。因此对于HTTP/2，gRPC等复杂的L7处理，基于eBPF的开发和维护都会比较困难。考虑到基础设施对性能、资源损耗的极致要求以及过往相关技术的演进规律，例如对于基础网络，绝大多数应用共享使用内核协议栈即可，部分特殊应用利用DPDK，RDMA等专用技术进行加速。同样，对于网格数据面，多种技术结合，分别优化相应场景的解决方案，可能是更具可行性的。可以预见，这类方案基本上是以类Ambient Mesh的节点级代理作为主体，随着网格以及eBPF技术的发展，将尽量多的网格数据面功能下沉至eBPF（Fast Path）实现；少部分高级功能交由用户态的Proxy（Slow Path）实现；那些对性能、隔离性等有较高要求的应用，则为其部署专属的Sidecar。这样一来，就能满足绝大多数场景下，对侵入性、性能、资源占用等各个维度的要求。综上 ，最终是一套数据面方案一统天下，还是各种方案混合部署，取各家所长，仍有待对相关技术不断探索演进，再用实践检验，最后让时间告诉我们答案。参考文献[1] Istio Ambient Mesh Explained: https://lp.solo.io/istio-ambient-mesh-explained[2] What to expect for ambient mesh in 2023: https://www.solo.io/blog/ambient-mesh-2023[3] Introducing Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh[4] Get Started with Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient

作者：华为云云原生团队▎边缘计算安全防护的实践与洞察随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。▎KubeEdge安全防护安全防护背景KubeEdge在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN等行业提供一体化的边端云协同解决方案。随着越来越多的用户将KubeEdge项目用于生产环境中， KubeEdge社区把安全问题放在优先地位，并成立Sig- Security 和安全团队 ，负责KubeEdge的系统安全设计，并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估，KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会（CNCF）对KubeEdge项目进行安全评估并输出安全评估报告，分析和总结KubeEdge项目的安全威胁模型及相关安全问题。该评估对KubeEdge项目的安全防护有重要的指导意义，感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski在该项工作中的巨大贡献，同时，感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会，他们对这次评估提供了很大帮助。对于安全报告中发现的安全问题，KubeEdge社区已根据社区的漏洞处理策略第一时间完成修复，并针对v1.11、v1.10、v1.9三个版本发布了安全补丁，版本号分别为v1.11.1、v1.10.2和v1.9.4，漏洞公告已发布在cid:link_4。接下来将通过解读KubeEdge威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。威胁模型分析KubeEdge的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用STRIDE威胁建模方法，结合安全审计报告对KubeEdge进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前KubeEdge社区已有的消减机制和安全加固建议。以下人群使用KubeEdge过程中，了解KubeEdge的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：• KubeEdge的贡献者：一个通用的威胁模型对KubeEdge贡献者很有用，他们可以从整体角度考虑并加固他们的系统。• 部署KubeEdge的组织：对于在集群中使用KubeEdge的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。• 安全评估员：负责评估KubeEdge及所属Kubernetes集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。• KubeEdge的用户及其开发人员：需要了解KubeEdge的更新和攻击，以主动避免未来可能发生的安全风险。外部攻击分析根据STRIDE威胁建模方法对KubeEdge潜在的外部攻击进行分析，对应的数据流图如下。如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界（引用自KubeEdge第三方安全报告）、社区已有的消减措施并给出安全加固建议。威胁一：云端CloudCore组件与EdgeCore组件之间的连接描述：该威胁涉及边缘EdgeCore与云端CloudCore之间的连接。在这个数据流中，较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。由于EdgeCore在系统中拥有独立的权限级别，攻击者控制EdgeCore后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控CloudCore来攻击其他节点（该漏洞描述引用自安全评估报告）。影响：攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。消减措施：• CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于KubeEdge项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 1和2）。威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务描述：边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：ServiceBus组件收到的数据往往是不受管理面控制的，攻击者能够对ServiceBus组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• ServiceBus组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止ServiceBus服务，阻止攻击继续进行；• ServiceBus服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。威胁三：边缘端Device通过MQTT Broker连接到EdgeCore描述：边缘device设备通过MQTT Broker（集成在EventBus组件中）连接到EdgeCore。该数据流中，较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问（该漏洞描述引用自安全评估报告）。影响：EdgeCore组件收到的数据往往是不受管理面控制的，攻击者能够对MQTT Broker发起恶意报文攻击，存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常，异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MQTT Broker仅监听在本机端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；同时，EventBus组件可作为客户端，对接外置第三方MQTT Broker，如果用户使用第三方MQTT Broker，详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。• EventBus仅对MQTT Broker中的特定Topic进行处理，用户无法通过该通道对EdgeCore任意访问。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、5和6）。威胁四：Edged管理和监控Pods及其他K8s资源描述：Edged管理和监控Pods及其他K8s资源。该数据流中，较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：如果Edged访问的CRI插件被攻击者恶意伪造，则存在CRI插件仿冒和篡改的威胁风险，导致本地业务异常。消减措施：• Edged与CRI插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化Unix domain sockets文件描述符的权限，避免被仿冒者恶意替换。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3和7）。威胁五：MetaServer在边缘节点提供HTTP服务描述：MetaServer作为边缘“api-server”，对边缘插件提供HTTP服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问（该漏洞描述引用自安全评估报告）。影响：MetaServer组件收到的数据往往是不受管理面控制的，攻击者能够对MetaServer组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MetaServer组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• MetaServer服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。内部攻击分析对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。消减措施：• KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代，该文档也将持续更新并完善。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、8和9）。供应链攻击分析攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。消减措施：• 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估，并引入SLSA软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。值得一提的是，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已达到SLSA L3等级（包括二进制和容器镜像构件），成为CNCF社区首个达到SLSA L3等级的项目，并加入Sigstore生态系统，实现更高等级的安全标准。• KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新，降低被攻击的风险；• KubeEdge security team已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 10和11）。安全加固建议列表Recommendation ID描述1使用安全长度的私钥加密，并加密保存私钥。建议用户生成至少为2048位私钥，且在本地加密存储私钥，存储私钥的文件设置最小化的访问权限，仅属主可读。2使用可信来源的CA证书。从可信的CA获取数字证书，不使用自签名证书。3严格限制边缘节点的本机权限，限制外部用户的用户登录权限，减少非必要的授权。4严格限制边缘节点应用部署的权限，只有系统服务和管理员才能拥有部署特权容器的权限。5在边缘节点部署应用时，严格校验应用镜像的合法性，防止部署恶意应用。6对于接入边缘节点的Device设备进行严格审核，避免非必要设备接入。7严格审查CRI插件的配置，使用CRI对应插件的官方推荐配置。8严格划分系统中各个角色权限，通过RBAC、OPA等方式实现系统角色权限的细粒度控制。9社区发现漏洞后将在最近的3个minor release版本中合入解决，用户可以关注社区security advisory 获取漏洞披露信息，及时跟进并更新KubeEdge版本。10用户使用社区发布的二进制文件前，应该根据社区发布的校验文件进行严格校验，防止二进制被仿冒和篡改。社区release软件包发布地址cid:link_6。11用户或vendors在使用源代码构建过程中，应该参考SLSA软件供应链安全评估框架，对源代码、构建流程、依赖库等进行安全加固。开源安全洞察本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。1) OpenSSF介绍社区工作组为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。相关项目1. OpenSSF最佳实践徽章（OpenSSF Best Practices Badge Program）开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过OpenSSF最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。2. 积分卡（Scorecards）通过Scorecards积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出0-10分数，帮助项目maintainer改进项目安全。3. 安全知识框架（Security Knowledge Framework）SKF是一个完全开源的Python-Flask / Angular网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。4. 安全开发指南提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等。5. 教育与培训课程提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期2年。6. 软件构建供应链级别（SLSA）软件构建的供应链级别SLSA由Google贡献给OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards是SLSA度量的工具组成部分。7. 令牌分发项目Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。8. 包管理最佳实践提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。当前文档还不完善，只重点介绍了npm，其它的包管理器待建设中。9. C/C++编译选项制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。10. 开源社区安全教育SIG当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。OpenSSF安全工具链安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。覆盖范围：涵盖整个DevSecOps的各环节工具链，并支撑开源软件开发的最佳实践章节，如：linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。提供方：部分来自公司捐赠，部分来自OpenSSF基金会自主规划，部分在规划阶段待建设。2) 开源软件安全动员计划及目标2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复• 缩短补丁响应时间：缩短漏洞披露和修复时间在2022年5月第二届开源软件安全峰会上，Linux基金会、OpenSSF及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下10个方向进行投资和安全改善，项目投资1.5亿美元，分为两年规划。备注：动员计划和OpenSSF工作组是相辅相成的，其动员计划的能力会融入到工作组中。投资方向描述安全培训向所有人提供基础安全软件开发培训和认证。风险评估为前 10,000 个（或更多）OSS 组件建立一个公开的、供应商中立的、客观的、基于指标的风险评估仪表板。数字签名加快在软件版本上采用数字签名。内存安全通过替换非内存安全语言来消除大多数漏洞的根本原因。事件响应建立一个由安全专家组成的 OpenSSF 事件响应团队，以协助开源项目加快对新发现漏洞的响应速度。安全扫描通过高级安全工具和专家指导，加快维护人员和专家发现新漏洞的速度。代码审计每年对200+个最关键的OSS组件进行一次第三方代码审查（以及任何必要的补救工作）。数据共享协调全行业的数据共享，以改善研究，帮助确定最关键的开放源码软件组件。SBOMs改进SBOM工具和培训，以推动采用。提升软件供应链安全用更好的供应链安全工具和最佳实践来增强10个关键的开放源码软件构建系统、软件包管理器和分发系统。▎总结本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。▎附录相关链接• 社区漏洞处理机制: cid:link_5• 安全审计报告: cid:link_1• 社区security advisory链接: cid:link_4• KubeEdge威胁模型及安全防护分析（本文档）: cid:link_0• 社区用户文档链接: https://kubeedge.io/en/docs• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats• KubeEdge实现SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/• Release版本发布链接: cid:link_6• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c• OpenSSF最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers添加小助手微信k8s2222，进入云原生交流群

张嘉伟近年来，Serverless服务崛起的趋势是有目共睹的：从Berkeley将Serverless认定为云计算向用户呈现的新默认形态[1]，到AWS、Google等头部厂商纷纷推出Serverless产品并成为爆款。这个趋势对于云计算平台是个必然，因为Serverless解放了用户管理和使用复杂云计算资源的双手，犹如第二次工业革命中内燃机汽车的出现解决了马车夫养马的麻烦，也推动高效、稳定的交通工具走进寻常百姓家。如同汽车由内燃机和转向机构等组件构成，Serverless平台可大致分为资源管理和任务编排[2]，分别致力于提供高效且灵活的算力以及提供方便的用户程序执行方式。在Serverless如火如荼的同时，Regionless也是不可忽视的一个方向。Regionless实际上是华为云提出的概念，即为屏蔽掉云平台Region的差异，使得云服务的租户能像“用水和用电”一样随时随地使用云服务。Regionless的内涵实际上是丰富的，囊括了多个学术研究方向：可以是geo-distributed cloud，也可以是multi-cloud，还可以是cloud-edge computing、 hybrid cloud等，分别对应不同的能力。恰好，以上都涵盖在华为云分布式云原生服务提供的offerings中。既然Serverless和Regionless都是当前云原生发展的重要方向，也都基于同一个云平台资源底座构建，那么两者的发展必然不会是平行的：Serverless对基础设施进行了标准化，为应用Regionless化减少了管理和适配的成本；反过来，Regionless也是Serverless的重要组成，因其可以避免用户感知Region间的差异。事实上，早在2018年，就有学者关注到Serverless对底层差异的屏蔽以及平台提供商数量的快速增长，用户必然会有将Serverless业务部署至Regionless平台的诉求[3]。在此场景下，用户和平台设计者首当其中考虑到的就是如何充分利用分布在各个区域的计算资源以提升如并发度、时延等性能；同时，使用成本也是用户核心关注点，所以如何充分利用各个厂商的定价差异消减成本，同时也避免与厂商绑定（vendor lock-in）带来潜在的成本问题也需要充分考虑。因此，本文尝试基于分析现有的学术文章，剖析Serverless与Regionless并存时，在性能提升和成本控制两个方向的现状与挑战，以期抛砖引玉。性能提升早在2019年，来自华盛顿大学的研究者[4]已经注意到Serverless工作流中的计算任务会涉及存储在不同区位的数据，并且这些数据在对应区位会存在隐私性等问题，因此需要将任务分布到对应数据所在的云平台Region进行计算。为此，作者设计了跨Region的调度器GlobalFlow，其核心思想是将工作流中的任务根据对Region的依赖关系进行分组，形成子工作流调度到对应Region，并且在子工作流之间设计Connector以便于数据交换。同样考虑到数据分布的问题，即数据可能分布在不同的区域，而且由于数据隐私性、传输开销等问题，并不能方便地集中在一个区域内处理，[5]中的作者设计了FaDO系统用以编排Serverless计算任务和数据。如图1所示，FaDO通过Backend Server记录每个区域存储的数据，这些信息则被提供给Load Balancer用于将用户请求的计算任务匹配并发送到对应的区域。并且在规则允许范围内，Backend Server还会将数据备份在不同的区域间进行复制，以配合计算任务的并发度。图1 FaDO系统执行流程除了数据的分布会促使Serverless必须接受Regionless，[6]的作者还观察到：一个云厂商的每个Region、每个厂商都有不同的并发度限制，并且之间的数据传输时延、存储的数据、每种任务执行的速度等能力均不一致。简单的将应用分发到多云/多Region上并不一定能充分提升并发度和整体完成时间。例如图2左侧所示（每种颜色标记的云上并发度限制为1000，整体应用由f1-f4任务构成，也需要运行1000次），如果f1在蓝色标识的云资源上运行地快，而f4则在橙色上快时，均匀分布则不能利用这个性能差异，而且在橙色云上，f2和f3并不能充分并行（完全并行需要1200并发度），进一步影响整体执行时间。在此情况下，如何合理选择任务所使用的云资源（如图2右侧所示），以有效地提升并发度是[6]所研究的重点。为此，[6]中提出了基于三层数学抽象构建的调度器算法FaaSt。FaaSt能够合理地将各个任务调度和合适的云厂商/Region上，使得整体的任务完成时间最短。经过在AWS和IBM云上4个Region的实验对比，FaaSt调度后的任务完成时间比单云提升2.82倍。图2 Serverless并发度示意图成本控制为了协助用户选择合适的平台以执行Serverless任务，[3]中提出了MPSC框架，其核心思想是通过实时监控Serverless任务在不同平台上执行的性能，进而选择最具性价比的平台。MPSC的架构如图3所示，其中Monitoring Controller为核心组件，用于协调监控指标采集分析和任务调度。Function Executor则负责将任务分发至各个平台执行，并采集对应指标。除此之外，还有三个存储模块分别用于储存用户配置、监控指标、用户定义的调度逻辑。图3 MPSC系统架构在Serverless任务能够合理分发的基础之上，来自CMU和UBC的学者提出了虚拟Serverless提供商（virtual Serverless provider, VSP）[7]的概念。VSP作为第三方的平台，聚合了各个厂商的Offerings，为用户提供统一的使用接口，为用户动态选择最具性价比的Offering。VSP整体架构如图4所示，其中核心组件包括：Scheduler用以根据性能指标和花费计算最合适的云平台；Controller则负责将应用请求映射到Scheduler选择的云平台上；Bridge用于不同云平台之间任务的交互；Monitor用以记录调度到不同平台上任务的执行性能；Pre-Load用于初始化新接入的云平台；而Cache则记录了平台执行情况用于后续分析优化。通过在AWS和Google云平台上的测试，VSP将Serverless任务的吞吐量提升了1.2-4.2倍，同时降低了54%的云资源使用成本。图4 VSP系统架构进一步地，一个面向多云Serverless的开源library在[8]中提出了。此library主要包括两部分内容（如图5所示）：1）统一的API和SDK，用于让用户不需要感知底层差异即可将不同人物部署在不同的云平台上，并且为了降低用户的学习门槛，还提供了基于某一家云平台提供商的API和SDK（如AWS）拓展出来的、可以将任务部署在其他云平台的API和SDK；2）分析系统（EAS），用于分析每个任务最适合的云平台，包含用于将任务分发至不同平台的adaptor、各个平台log的收集器Cloud Logging Query、各个云厂商的计费模型Cost Model、接入各个云平台的鉴权组件Authentication、任务执行的记录Local Logging以及性能分析器Analysis。图5 面向多云的Serverless开源library挑战从上述现有工作可以看出，当前学术界对于Regionless和Serverless结合的研究主要面向geo-distributed cloud和multi-cloud这两个场景下的任务编排系统架构和算法。然而这还远远不足以构建高效、易用的Regionless化的Serverless平台。类似于Berkeley将Serverless分成Backend-as-a-Service (BaaS)和Function-as-a-Service (FaaS)两个层级[1]，我们也可以将当前所面临的挑战拆分成底层资源供给以及上层应用管理在Regionless场景的Serverless化：• 底层资源上，我们需要考虑：1) 通盘考虑每个区域计算资源池的异构性、资源余量、成本等因素的情况下，提供足够的资源同时又不因为Serverless极强的弹性而造成过多浪费[9]；2) 从网络角度，在规避部分地理区位间带宽、时间等限制的同时，提供支持动态创删的低性能损失、免配置的网络；3) 存储上，提供用户无感知的跨Region数据预存取与缓存。• 应用管理层面上看，需要达到如下：%2) 任务编排上，需要对计算、网络、存储联合进行调度以避免其中某项瓶颈对整体应用的影响；%2) 编程框架上，需要在最小甚至没有侵入式修改的前提下，将用户应用构建或迁移至该平台；%2) 从监控运维角度，需要实现非侵入式、高精度地采集Serverless实例的指标，并基于分布在各个区域的监控数据进行智能异常检测、根因分析。以上也将云厂商和学术界共同打造高效且易用的Regionless下Serverless平台，共同面临的挑战。参考文献[1] J. Schleier-Smith, et. al. "What serverless computing is and should become: The next phase of cloud computing," Communications of the ACM, vol. 64, no.5, pp. 76-84, 2021.[2] Li, Zijun, et. al. "The serverless computing survey: A technical primer for design architecture." ACM Computing Surveys (CSUR), vol. 54, no.10s, pp. 1-34, 2022.[3] A. Aske, et. al. "Supporting multi-provider serverless computing on the edge," in Proc. Int. Conf. Parallel Processing Companion, 2018.[4] G. Zheng, et. al. "GlobalFlow: a cross-region orchestration service for serverless computing services," in Proc. IEEE Int. Conf. Cloud Comput. (CLOUD), 2019.[5] C. Smith, et. al. "Fado: Faas functions and data orchestrator for multiple serverless edge-cloud clusters," in Proc. IEEE Int. Conf. Fog and Edge Comput. (ICFEC), 2022.[6] S. Ristov, et. al, "FaaSt: Optimize makespan of serverless workflows in federated commercial FaaS," in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), 2022.[7] A. Baarzi, et. al. "On merits and viability of multi-cloud Serverless," in Proc. ACM Symp. Cloud Comput., 2021.[8] H. Zhao, et al. "Supporting Multi-Cloud in Serverless Computing," arXiv preprint arXiv:2209.09367, 2022.[9] A. Mampage, et. al. "A holistic view on resource management in serverless computing environments: Taxonomy and future directions," ACM Computing Surveys (CSUR), vol. 54, no. 11s, pp. 1-36, 2022.添加小助手微信k8s2222，进入云原生交流群