Karmada 社区非常高兴地宣布正式成立 Karmada Adopter Group（中文名称：Karmada 用户组）。这一举措旨在创建一个充满活力的平台，让用户能够互相连接、合作及高效的信息分享。通过营造共享经验和相互支持的环境，Karmada Adopter Group 将成为用户与 Karmada 社区之间的关键纽带。 作为开放的多云多集群容器编排引擎，Karmada 社区（https://karmada.io/）自2021年开源以来迅速发展，并于2023年12月成为 CNCF 孵化级项目，贡献者遍布全球20+国家和地区。Karmada现已成功部署于数十家大型企业的生产环境中，被广泛应用于公司级关键技术底座，全面管理企业的通用及异构算力资源。 Karmada 不仅获得了大量用户的积极支持，还通过用户的宝贵反馈不断优化和完善。这些支持包括但不限于详细的使用反馈、问题修复以及丰富的实战经验分享，极大地促进了项目的成熟与稳定。社区成员之间的紧密合作，使得Karmada能够快速响应并解决实际应用中的挑战，持续提升用户体验。为了进一步促进用户的交流和合作，Karmada用户现在可以通过加入用户组，连接全球开发者，共同探讨和构建多集群技术。这不仅促进了技术交流和最佳实践分享，也为用户的持续创新和发展提供了坚实的基础。无论是新手还是资深用户，都能在这里找到所需的知识和帮助，共同推动Karmada及其生态系统的繁荣发展。 Karmada 用户组介绍 Karmada Adopter Group 拥有一个专属的 Google 邮件组以及 GitHub Org 组，用于重要公告、更新和信息共享，其主要目标与功能包括：分享知识：促进 Karmada 用户之间经验、挑战和解决方案的交流促进协作：提供一个用户可以共同工作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度 加入用户组，您可以解锁的权益 加入Karmada Adopter Group，您可以与面临类似挑战的同行建立联系并分享Karmada实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括KubeCon等海内外业界大会，Karmada社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要Bug修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作 如何加入用户组 任何在生产环境中使用Karmada的公司，其开发者均可申请加入Karmada Adopter Group。无论您是最终用户还是供应商，我们都欢迎您的参与。最终用户：指在其内部IT基础设施中直接部署和使用Karmada进行多云或多集群管理的企业或组织。这些公司利用Karmada作为关键技术底座来管理和优化其全部算力资源。供应商：指那些将Karmada集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。当前，加入Karmada Adopter Group对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对Karmama社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方Karmada用户组申请表单，提交issue申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组用户组申请链接：[1] Karmada Adopter Group 申请加入表单地址：cid:link_0[2] 更多Karmada Adopter Group 详细信息，请查阅：cid:link_2 Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系:Hongcai Ren (@RainbowMango) qdurenhongcai@gmail.comMaintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io  添加社区小助手进入Karmada交流群 👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_3Slack地址：https://slack.cncf.io/（#karmada）

由Linux Foundation组织的LFX Mentorship计划，从19年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。往年已获16w+申请，发起1200+课题，毕业近1000实习生，发放超过300万美金报酬。 2025年春季申请时间  2月18日截止 ，远程实习将从 3 月 3 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为 $3000美金，约合￥20000人民币）。   Karmada社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者请于截止日期前在官方入口申请 cid:link_5 Karmada社区介绍Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。Karmada社区贡献者遍布全球20+国家和地区，现已成功部署于数十家大型企业的生产环境中，被广泛应用于公司级关键技术底座，全面管理企业的通用及异构算力资源。在LFX Mentorship 2025春季计划，Karmada期待与你协作开拓AI大数据等场景调度的更多可能。  面向对象 春季计划申请者需在2025年2月18日前在LFX官网完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定[1]，对Mentee申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求 课题参与方式 根据官方安排 [2]，LFX Mentorship 2025年春季活动流程如下：Mentee注册与项目申请 February 5 - 18, 2025 申请者审核期 February 19 - 25申请者入选通知 February 26实习启动March 3中期考核April 15首次津贴支付April 16结项考核、实习生报告提交 May 27最终薪酬支付批准 May 28活动结束 May 30申请者需要在2月18日前完成Mentee注册和项目申请，流程详见 [3]：cid:link_4实习申请结果预计将在 2 月 26 日通知到申请人。主线开发日期为2025年3月3日-5月27日，全程线上协作，无需线下参与。结项需要在2025年5月27日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。 Karmada社区课题  今年，我们向各位申请者推荐CNCF Karmada 社区下列课题：   ▍Karmada Self-Signed Certificate Content Standardization课题描述：在现有的 Karmada 架构中，每个组件都应该有自己独特的证书，以确保明确的身份和安全性。最佳实践要求每个组件的名称在其证书中用作通用名称（CN），以便于身份区分。然而，目前，所有的 Karmada 组件共享相同的证书内容，这导致了混乱和潜在的安全风险。这个项目的目标是通过确保每个组件拥有反映其身份的不同证书来提高 Karmada 证书系统的合规性。这将提高系统安全性，降低管理复杂性，并与行业标准保持一致。这个项目旨在实现以下标准：- 为整个 Karmada 系统使用单个 CA 证书。- 为每个服务器组件颁发单独的服务器证书，使用组件名称作为 CN。- 为每个客户端组件颁发单独的客户端证书，使用组件名称作为 CN，同一客户端可以为不同的服务器使用一致的证书。 预期结果：- 为 8 个服务器组件完成不同证书的颁发，并将证书内容导入到相应的证书 Secrets 中。- 为 11 个客户端组件完成不同证书的颁发，并将证书内容导入到相应的证书 Secrets 或 Config Secrets 中。 前置技能：Go，Kubernetes，Karmada 课题导师：Chaosi Pan（@chaosi-zju ）chaosi@zju.edu.cnZhen Chang （@XiShanYongYe-Chang ）changzhen5@huawei.com 课题链接：cid:link_1▍Implement multi-cluster management in the Karmada dashboard课题描述：Karmada dashboard 已经实现了控制平面中资源的管理。除此之外，我们希望实现成员集群中资源的管理：一旦用户在控制平面上添加 Kubernetes 资源和相应的策略资源，他们就可以无缝切换到相应的成员集群，检查特定成员集群中 Kubernetes 资源的状态。Kubernetes dashboard 是最受欢迎的单集群管理工具之一，它使用 client-go sdk 与 apiserver 通信以管理集群中的资源。由于 karmada-aggregated-apiserver 组件以及 Kubernetes 资源和 Karmada 资源之间的兼容性设计，大量与 client-go 相关的逻辑可以很容易地扩展到多集群。因此，我们希望将 Kubernetes dashboard 与 karmada-aggregated-apiserver 组件结合起来，在 Karmada dashboard 中实现多集群管理。 预期结果：- 根据 karmada-aggregated-apiserver 提出多集群管理方案。- 将具有特定版本的 Kubernetes dashboard 同步到 Karmada dashboard 仓库，并基于 karmada-aggregated-apiserver 在成员集群中实施资源管理。- 成员集群管理的典型用户界面：- 为 deployment 资源增加 list/detail/delete/update 操作。- pod 资源的日志查看器。- pod 资源的网络终端，用户可以附加正在运行的 pod，并执行临时命令。 前置技能：Kubernetes, Go, gin, react, webgl 课题导师：Wenjiang Ding（@warjiang ）1096409085@qq.comZhen Chang （@XiShanYongYe-Chang ）changzhen5@huawei.com 课题链接：cid:link_2 如果对课题实习有任何问题，欢迎向课题导师发送邮件或在GitHub仓库提交Issue提问。 扫码回复“Karmada” 进入技术群  今年春季，Karmada社区期待在 LFX Mentorship 见到您！ 参考资料[1] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible [2] LFX Mentorship - Program Readme: cid:link_0[3] LFX Mentorship - Mentee Application Guideline: cid:link_4   👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_6Slack地址：https://slack.cncf.io/（#karmada）

北京时间2025年1月21日，KubeEdge 发布1.20.0版本。新版本针对大规模、离线等边缘场景对边缘节点和应用的管理、运维等能力进行了增强，同时新增了多语言 Mapper-Framework 的支持。   KubeEdge v1.20.0 新增特性：支持批量节点操作 多语言 Mapper-Framework 支持 边缘 keadm ctl 新增 pods logs/exec/describe 和 Devices get/edit/describe 能力解耦边缘应用与节点组，支持使用 Node LabelSelector边云通道支持 IPv6升级 k8s 依赖到1.30   新特性概览   ▍支持批量节点操作在之前的版本中，keadm 工具仅支持单个节点的安装与管理，然而在边缘场景中，节点数量通常比较庞大，单个节点的管理难以满足大规模场景的需求。在1.20.0版本中，我们提供了批量节点操作和运维的能力。基于这个能力，用户仅需要使用一个配置文件，即可通过一个控制节点（控制节点可以登录所有边缘节点）对所有边缘节点进行批量操作和维护。keadm 当前版本支持的批量能力包括 join, reset 和 upgrade。# 配置文件配置要求参考如下 keadm: download: enable: true # <Optional> Whether to download the keadm package, which can be left unconfigured, default is true. if it is false, the 'offlinePackageDir' will be used. url: "" # <Optional> The download address of the keadm package, which can be left unconfigured. If this parameter is not configured, the official github repository will be used by default. keadmVersion: "" # <Required> The version of keadm to be installed. for example: v1.19.0 archGroup: # <Required> This parameter can configure one or more of amd64/arm64/arm. - amd64 offlinePackageDir: "" # <Optional> The path of the offline package. When download.enable is true, this parameter can be left unconfigured. cmdTplArgs: # <Optional> This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd. cmd: "" # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd. token: "" # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd. nodes: - nodeName: edge-node # <Required> Unique name, used to identify the node arch: amd64 # <Required> The architecture of the node, which can be configured as amd64/arm64/arm keadmCmd: "" # <Required> The command to be executed on the node, can used in conjunction with keadm.cmdTplArgs. for example: "{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}" copyFrom: "" # <Optional> The path of the file to be copied from the local machine to the node, which can be left unconfigured. ssh: ip: "" # <Required> The IP address of the node. username: root # <Required> The username of the node, need administrator permissions. port: 22 # <Optional> The port number of the node, the default is 22. auth: # Log in to the node with a private key or password, only one of them can be configured. type: password # <Required> The value can be configured as 'password' or 'privateKey'. passwordAuth: # It can be configured as 'passwordAuth' or 'privateKeyAuth'. password: "" # <Required> The key can be configured as 'password' or 'privateKeyPath'. maxRunNum: 5 # <Optional> The maximum number of concurrent executions, which can be left unconfigured. The default is 5.` # 配置文件参考用例 (各字段具体值请根据实际环境进行配置) keadm: download: enable: true url: cid:link_11/releases/download/v1.20.0 # If this parameter is not configured, the official github repository will be used by default keadmVersion: v1.20.0 archGroup: # This parameter can configure one or more of amd64\arm64\arm - amd64 offlinePackageDir: /tmp/kubeedge/keadm/package/amd64 # When download.enable is true, this parameter can be left unconfigured cmdTplArgs: # This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd cmd: join--cgroupdriver=cgroupfs--cloudcore-ipport=192.168.1.102:10000--hub-protocol=websocket--certport=10002--image-repository=docker.m.daocloud.io/kubeedge--kubeedge-version=v1.20.0--remote-runtime-endpoint=unix:///run/containerd/containerd.sock token: xxx nodes: - nodeName: ubuntu1 # Unique name arch: amd64 keadmCmd: '{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}' # Used in conjunction with keadm.cmdTplArgs copyFrom: /root/test-keadm-batchjoin # The file directory that needs to be remotely accessed to the joining node ssh: ip: 192.168.1.103 username: root auth: type: privateKey # Log in to the node using a private key privateKeyAuth: privateKeyPath: /root/ssh/id_rsa - nodeName: ubuntu2 arch: amd64 keadmCmd: join--edgenode-name=containerd-node2--cgroupdriver=cgroupfs--cloudcore-ipport=192.168.1.102:10000--hub-protocol=websocket--certport=10002--image-repository=docker.m.daocloud.io/kubeedge--kubeedge-version=v1.20.0--remote-runtime-endpoint=unix:///run/containerd/containerd.sock # Used alone copyFrom: /root/test-keadm-batchjoin ssh: ip:192.168.1.104 username: root auth: type: password passwordAuth: password: ***** maxRunNum: 5 # 用法 (保存以上文件，例如保存为 config.yaml) # 在控制节点下载最新版本 keadm, 执行以下命令进行使用 keadmbatch-c config.yaml更多信息可参考：cid:link_3cid:link_4cid:link_10 ▍多语言 Mapper-Framework 支持由于边缘 IoT 设备通信协议的多样性，用户可能需要使用 Mapper-Framework 生成自定义 Mapper 插件来纳管边缘设备。当前 Mapper-Framework 只能生成 go 语言版本的 Mapper 工程，对于部分不熟悉 go 语言的开发者来说使用门槛仍然较高。因此在新版本中，KubeEdge 提供了 Java 版本的 Mapper-Framework，用户可以访问 KubeEdge 主仓库的feature-multilingual-mapper分支，利用 Mapper-Framework 生成 Java 版的自定义 Mapper 工程。更多信息可参考：cid:link_11/pull/5773cid:link_5 ▍边缘 keadm ctl 新增 pods logs/exec/describe 和 Devices get/edit/describe 能力在v1.17.0版本中，我们新增了 keadm ctl 子命令，支持在离线场景下对边缘 pod 进行查询和重启。在v1.20中我们对该命令做了进一步增强，支持 pod 的logs/exec/describe等功能，用户在边缘可对 pod 进行日志查询、pod 资源详细信息查询、进入容器内部等操作。同时还新增了对 device 的操作，支持 device 的get/edit/describe的功能，可以在边缘获取 device 列表、device 的详细信息查询、在边缘离线场景下对 device 进行编辑操作。如下所示，新增的 keadm ctl 子命令功能均在 MetaServer 中开放了 Restful 接口，并与 K8s ApiServer 对应的接口完全兼容。[root@edgenode1 ~] # keadm ctl -h Commands operating on the data plane at edge Usage: keadm ctl [command] Available Commands: ... describe Show details of a specific resource edit Edit a specific resource exec Execute command in edge pod get Get resources in edge node logs Get pod logs in edge node ...更多信息可参考：cid:link_6cid:link_7 ▍解耦边缘应用与节点组，支持使用 Node LabelSelectorEdgeApplication 可以通过节点组覆盖部署定义（如副本、镜像、命令和环境），Pod 流量在节点组内闭环（EdgeApplication 管理的 Deployment 共用一个 Service）。但在实际场景中，需要批量操作的节点范围与需要相互协作的节点范围并不相同。例如在智慧园区的场景中，每个城市都有很多个智慧园区，我们需要应用的流量在一个智慧园区内闭环，但应用批量管理的范围可能是城市级，也可能是省级。我们在EdgeApplication CRD中为节点标签选择器添加了一个新的targetNodeLabels字段，该字段将允许应用程序根据节点标签进行部署，并且覆盖特定的字段，YAML 定义如下：apiVersion: apps.kubeedge.io/v1alpha1 kind: EdgeApplication metadata: name: edge-app namespace: default spec: workloadTemplate: {...} workloadScope: # New field: targetNodeLabels targetNodeLabels: - labelselector: - matchExpressions: - key: "region" operator: In values: - "HangZhou" overriders: {...}更多信息可参考：Issue: cid:link_2Pull Request: cid:link_8 ▍边云通道支持 IPv6我们在官网的文档中提供了一份配置指南，介绍了 KubeEdge 如何在 Kubernetes 集群中让云边 hub 隧道支持 IPv6。文档地址：https://kubeedge.io/docs/advanced/support_ipv6 ▍升级 K8s 依赖到 v1.30 新版本将依赖的 Kubernetes 版本升级到v1.30.7，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_9  本升级注意事项  从v1.20开始，EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet。如果您需要继续使用原有路径，可以在使用 keadm 安装 EdgeCore 时设置--set edged.rootDirectory=/var/lib/edged。 ▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.20版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！ ▍相关链接Release Notes：cid:link_1  扫码回复“KubeEdge” 进入技术群    【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。 课程免费学习链接：cid:link_0 KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。 KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_11Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获16w+申请，发起1200+课题，毕业近千名实习生，发放超过300万美金报酬。2025年春季申请时间为 2月5日-2月18日，远程实习将从3月3日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于2月18日前点击阅读全文，或到官方平台申请：strongcid:link_14/strong  KubeEdge社区介绍 KubeEdge 社区已经连续5年参与 LFX Mentorship 计划，过去已为学员提供25+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8k+Stars和2.2k+Fork，吸引了全球来自35+国家的100+贡献组织及16万+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。在 LFX Mentorship 2025春季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象 春季计划申请者需在2025年2月18日前在 LFX 官网完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定[1]，对 Mentee 的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求   课题参与方式  根据官方安排 [2]，LFX Mentorship 2025年春季活动流程如下：Mentee 注册与项目申请 2月5日-2月18日申请者评审及人事工作 2月19日-2月25日实习启动及任务发放 3月3日中期考核及首次津贴支付 4月16日结项考核、实习生报告提交，最终津贴支付批准 5月28日 活动结束 5月30日申请者需要在2月18日前完成 Mentee 注册和项目申请，流程详见 [3]：cid:link_8实习申请结果预计将在 2 月 26 日通知到申请人。主线开发日期为2025年3月3日 – 5月28日，全程线上协作，无需线下参与。结项需要在2025年5月28日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。   KubeEdge课题    最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍KubeEdge: Enhance KubeEdge testing coverage (2025 Term 1)课题描述：为更好地维护代码质量并减少缺陷的引入，本课题希望将单元测试覆盖率提高到60%到70%（目前单元测试覆盖率为38.69%）。需要注意的是，除了要求 KubeEdge 整体的单元测试覆盖率满足要求外，每个核心代码目录（cloud/、edge/、keadm/和pkg/）的单元测试覆盖率也需要超过60%。预计输出件：UT 覆盖率提升至60%-70%前置技能：KubeEdge, Go, Testing课题导师：Elias Wang (@wbc6080)wangbincheng4@huawei.comFisher Xu (@fisherxu)fisherxu1@gmail.com课题链接：cid:link_2Github Issue：cid:link_9 ▍KubeEdge: KubeEdge Dashboard Enhancement - BFF (2025 Term 1)课题描述：为 KubeEdge Dashboard 设计的 BFF（Backend for Frontend） 中间层，旨在连接前端 UI 层与 KubeEdge 后端 API，作为数据的中转和处理中心，为前端提供一个专门设计的后端服务，简化前端的数据获取逻辑并提升性能与安全性。此外，为了让开发者更快速地体验并部署Dashboard，我们需要与 kubeedge/keink 项目进行深度集成，仅需一条命令即可启动 Dashboard 环境，实现对功能的完整演示和验证。预计输出件：一键运行与持续集成一键部署： 借助 keink 项目，仅需一条命令即可快速拉取并运行 Daily 发布的容器镜像，让开发者或体验者无需额外环境配置。持续发布机制： Daily 镜像能够持续整合最新的功能更新和修复，开发者可以及时获取最新版本，快速验证和测试功能，从而优化研发流程。数据处理: 对从后端获取的数据进行统一的格式化、过滤和处理，以满足前端的展示需求，避免在前端编写重复或复杂的逻辑。错误处理与重试（可选）前置技能：KubeEdge, JavaScript, React课题导师：Chen Su (@ghosind)ghosind@gmail.comElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：cid:link_3Github Issue：cid:link_10 ▍KubeEdge: Domain-specific large model benchmarks: the edge perspective (2025 Term 1)课题描述：业界通用大模型基准测试往往聚焦于云。随着大模型进入规模化应用时代，云端为大模型提供了基础设施和服务。客户进一步提出了边缘侧的针对性应用需求，包括个性化、数据合规性和实时性，使得不同边侧单位往往构建自有行业大模型或知识库。但目前针对边侧数据开展的大模型基准测试并未成型。由于数据在不同边缘的分布，预计通用大模型在多样边侧行业场景将产生大幅性能波动。本课题旨在为边缘AI服务和应用定位行业大模型性能波动，以便用于匹配特定大模型、定位问题乃至选择适用边侧场景。预计输出件：行业大模型边侧测试数据集、测试套件、使用说明（进阶) 测试指标设计与开发（进阶）测试方法研究，测试调研与研究报告前置技能：KubeEdge-Ianvs, Python, LLMs课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@hotmail.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：cid:link_4Github Issue：cid:link_12 ▍KubeEdge: Enhance Dependency Management and Documentation for KubeEdge-Ianvs (2025 Term 1)课题描述：Ianvs目前正面临着较为紧迫的依赖管理问题。随着 Python 版本、依赖库以及 Ianvs 特性的持续演进，许多先前的 examples 已无法运行，导致大量相关的 Issue 被提出；现有的项目文档中也存在不少过时内容，这对新用户来说较为困扰。Ianvs 需要对已有 examples 的依赖进行梳理，并构建一套更加完善的依赖管理机制，降低新用户上手Ianvs的门槛。预计输出件：更加完善的 Contributing Guide基于大语言模型云边协同推理示例打造的全新 Quick Start Example其他 Paradigm 依赖修复和文档完善前置技能：KubeEdge, Python课题导师：Yu Fan (@FuryMartin)furymartin9910@outlook.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：cid:link_5Github Issue：cid:link_13 ▍KubeEdge: Community Website Comprehensive Upgrade Project: Homepage Renewal… (2025 Term 1)课题描述：为提高 KubeEdge 官网的用户体验和访问效率，官网优化项目将聚焦于首页设计优化、新页面的增加以及社区资源的改进。该项目的目标是提升网站的易用性、增加用户粘性，并通过增强培训内容和硬件兼容性支持，吸引更多用户使用 KubeEdge。预计输出件：官网首页的设计与优化，包含设计和代码更新新增页面：课程培训视频的展示，包含设计和代码更新新增页面：”硬件兼容”展示页，包含设计和代码更新partner 页面设计与优化，包含设计和代码更新优化社区资源，改善文档和入门体验，确保用户能够轻松上手并有效使用  KubeEdge。前置技能：KubeEdge, JavaScript, Docusaurus课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：cid:link_6Github Issue：cid:link_11如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。扫码回复“KubeEdge” 进入技术群今年春季，KubeEdge 社区期待在 LFX Mentorship 见到您！ 参考资料：[1] LFX Mentorship - Application Requirement：cid:link_7 [2] LFX Mentorship - Program Readme：cid:link_0[3] LFX Mentorship - Mentee Application Guideline：cid:link_8  【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_1KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。 KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_15Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

点击可前往>>华为云AI原生应用引擎官网 往期回顾1、【新特性上线】华为云AI原生应用引擎新增特性介绍（2024年10月发布）2、【新特性上线】华为云AI原生应用引擎新增特性介绍（2024年11月发布）3、【新特性上线】华为云AI原生应用引擎新增特性介绍（2024年12月发布） 

点击可前往>>华为云AI原生应用引擎官网 往期回顾1、【新特性上线】华为云AI原生应用引擎新增特性介绍（2024年10月发布） 2、【新特性上线】华为云AI原生应用引擎新增特性介绍（2024年11月发布）

点击可前往>>华为云AI原生应用引擎官网   往期回顾1、【新特性上线】华为云AI原生应用引擎新增特性介绍（2024年10月发布）

点击可前往>>华为云AI原生应用引擎官网   

2024年12月18日，由中国科学技术协会科学技术传播中心、中国计算机学会、中国通信学会、中国科学院软件研究所联合主办，CSDN 承办的开源创新榜评选活动圆满落幕。KubeEdge 作为业界首个云原生边缘计算项目以及 CNCF 唯一正式毕业的边缘计算开源项目，以其卓越的创新性、贡献度和影响力，从200多个竞争项目中脱颖而出，荣获2024开源创新榜优秀开源项目之首。2024开源创新榜评选活动由王怀民院士担任评委会主任，带领全国各学会、大学、科研院所、企业、开源基金会、行业联盟等近20位开源专家，面向中国开源行业领域，遴选具有创新性、贡献度和影响力的开源项目、社区、应用场景与开源事件，进一步激励更多企业和开发者参与开源生态建设，推动开源技术繁荣和发展。KubeEdge 于2018年11月正式开源，2019年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目，在2020年9月晋升为孵化项目，并于2024年10月从 CNCF 正式毕业，是第三个由中国企业开源的毕业项目。KubeEdge 项目致力于将 Kubernetes 的容器化应用编排能力无缝扩展至边缘主机，为边缘计算提供强大的基础设施支持。它基于 Kubernetes 构建，不仅覆盖了云端与边缘端之间的网络连接、应用部署和元数据同步，还通过高效的架构设计，显著提升了边缘计算场景中的可靠性与性能。目前，KubeEdge 将云原生生态扩展到了数据中心之外的更多场景和行业，广泛应用于 CDN、智能交通、智慧能源、智慧零售、智慧园区、智能汽车、航空航天、智能物流、金融、化工、电力、区块链等各领域，完成了业界最大规模云原生边云协同高速公路收费站管理项目、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生智慧零售管理、业界首个云原生金融管理等行业代表项目。基于云原生边缘计算领域的独特优势，KubeEdge 得到了伙伴和用户的高度认可。此次荣获“优秀开源项目”奖项，既是对 KubeEdge 技术实力的高度认可，也彰显了社区在合作精神、开放性和追求卓越方面的努力与成就。这一荣誉离不开每一位社区成员的辛勤付出和无私奉献。未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步改善用户体验，提供更可靠和稳定的服务。我们也诚邀更多的开发者和用户加入 KubeEdge 社区，共同探索边缘计算的未来，共创辉煌。 【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

12月27日，“The Future of KubeEdge” KubeEdge 毕业主题研讨会在上海成功举办。来自上海开源信息技术协会、华为云、DaoCloud、Intel、南京腾优科技、FatCoupon Technology、中碳普惠云、复旦大学、上海对外经贸大学、上海工程技术大学等多家机构、企业、高校代表及贡献者出席，就 KubeEdge 毕业后的社区规划展开深入研讨，持续聚力技术与运营协同创新，助力云原生边缘计算产业升级发展。  回顾 KubeEdge 的发展历程，从 2018 年 11 月正式开源，2019 年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目， 2020 年 9 月晋升为孵化项目，并于2024年成功毕业，成为CNCF首个毕业级云原生边缘计算项目，一路走来，社区持续开源创新，将云原生生态扩展到了数据中心之外的更多场景和行业，为业内带来了多个行业首发应用，广泛覆盖 CDN、智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、电力、区块链等领域。 ▲ KubeEdge 项目里程碑 会上，KubeEdge 联合创始人，华为云云原生开源负责人王泽锋介绍了全球云原生开源生态与运作模式，并分享了 KubeEdge 发展历程中的核心技术与典型案例。CNCF 毕业项目是国际开源生态的领军者，KubeEdge 从 CNCF 毕业已迈入了成熟新阶段。基于在云原生边缘计算领域的独特优势，KubeEdge 期待在未来为整个云原生生态系统缔造更广阔的可能性。 ▲ KubeEdge联合创始人，华为云云原生开源负责人王泽锋 KubeEdge TSC，DaoCloud 首席运营官张红兵在会上分享了 KubeEdge 长期以来的社区治理及运营策略。通过系统化建立社区治理架构，严格执行高效的开发者协同机制，开展深度的工程化验证，社区有序促进技术持续创新与升级。与此同时，社区也通过开发者实训、公开课、峰会、研讨会等系列形式，为社区开发者们构建多元化的学习、参与和成长路径，打造社区活跃生态。 ▲ KubeEdge TSC，DaoCloud 首席运营官张红兵 毕业是社区的里程碑，同时也对技术创新和运营发展提出了更高的要求。在小组讨论环节，各位代表集思广益，从企业、高校、开发者各个视角，就社区未来发展深入探讨，涵盖 Scalability、Node、Device-IoT、AI、Netwoking、Security、UI、Cluster-Lifecycle、Testing、EdgeSite、Release、Docs、Robotics 等多个 SIG 的技术创新方向，持续升级社区运营治理，促进 KubeEdge 与产业发展生态融合。 未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步升级用户体验，提供更可靠和稳定的服务。社区成功毕业离不开每一位社区伙伴、用户与开发者的协作与贡献，期待与您携手共建，加速社区生态协同发展，共同引领云原生边缘计算迈向产业应用新高度。

 OSI七层参考模型：开放式系统互联 OSI/RM  ISO—国际公有化组织 --分层以各司其职  分层作用：降低层次间的关联性，上层都在下层的基础上提供增值服务  七层：应用层-表示层-会话层-传输层-网络层-数据链路层-物理层  应用层---应用程序  表示层---抽象语言转化为二进制  会话层---建立维护和断开一次链接（主机和服务器间建立的会话通讯）  传输层：端到端的传输，应用到应用间的传输，区分进程和服务。  端口号：16位二进制构成0-65535，真正使用的是1-1023端口号（称为知名端口号，著名端口号）  HTTP协议（超文本传输，可传输图片、声音等）：TCP 80端口（Dport） web访问需要用到的协议  HTTPS协议（“S”: SSL安全协议，比HTTP更安全）：443端口（Dport）  访问网站流程：sport：x  Dport：443  发送                Sport：443  Dport：x  回复  网络层  数据链路层：介质访问控制层（MAC）+逻辑链路控制层（LLC）  物理层：一串电流  协议簇：     PCU—协议数据单元（命名）  应用层—数据报文  传输层—数据段  网络层—数据包  数据链路层—数据帧（掉帧即为该层数据丢失）  物理层—比特流  封装：从应用层开始到数据链路层结束，物理层为电流不需要封装。    解封装：把封装的协议包层层解开得到数据。   应用层：        传输层：TCP协议 UDP协议  TCP与UDP协议的区别：  TCP优点：  1.TCP是面向连接的协议，UDP是无连接的协议---TCP的三次握手 2.TCP是可靠的传输层协议，UDP是一种“尽力而为”的协议，排序，确认，重传，流控 3.TCP可以进行分段，UDP不能进行数据分段（数据分段：对大型数据传输中将其分成多个小数据多次传送，“大而化小”降低影响） 4.TCP可以进行流量控制（在某一时间点控制发送或接受数据包数量），而UDP不能  UDP优点：  1.TCP传输速率慢，而UDP传输速率快，TCP（参数多）资源占用比较大，而UDP资源占用小 Sum：即时通讯类会采用UDP，文件、邮件这一类对可靠性要求较高的数据采用TCP进行传输  最小长度（无选项）：5*4=20字节   UDP：   校验和：校验数据完整性，在发送 TCP 数据段时，由发送端计算校验和，当到达目的地时又进行一次检验和计算。如果两次校验和一致，说明数据是正确的，否则将认为数据被破坏，接收端将丢弃该数据。  伪头部校验—除了校验自身协议头部内容外，还会校验部分IP协议的内容  可变长头部---首部长度：标注TCP头部大小  FIN—发送端完成位，提出断开连接一方要把FIN置为1表示断开连接  SYN—同步序号位，TCP建立时要设置该值为1  URG—紧急标志位  ACK—确认标志位（为1表示确认号）  PSH—推送  TCP的三次握手：      1.发送一个SYN包，并等待确认，标志位为SYN=1，表示请求建立连接；序号为Seq = x（x 一般取随机数）；  2.接收到发来的SYN包后，对该包进行确认后结束，并返回一段 TCP 报文。标志位为SYN和 ACK，表示确认客户端的报文 Seq 序号有效，能正常接收A发送的数据，并同意创建新连接； 序号为 Seq = y；确认号为 Ackn（ack）= x + 1，表示收到序号 Seq 并将其值加 1 作为自己确认号 Ack 的值（询问下一个数据包）。  3.接收到发送的 SYN + ACK 包后，明确了数据传输是正常的，并返回最后一段报文。标志位为 ACK，表示确认收到同意连接的信号；序号为 Seq = x + 1，表示收到确认号 Ack，并将其值作为自己的序号值；确认号为 Ack= y + 1，表示收到服务器端序号 seq，并将其值加 1 作为自己的确认号 Ack 的值。  四次挥手：   流控：滑动窗口机制  发送时Ack=1、2、3、4，win=4（发几个就是几）  接收时Ack=5，win=4（收几个就是几）  下一次发送时win会增大，随后会跟随用户网速逐渐减小/增大  网络层：IP协议   MTU—最大传输单元：1500字节  默认携带的最大数据量—1500-20（tcp）-20（ip）=1460字节  MSS—最大段长度1480  生存时间—每经过一个路由器的转发，这个TTL的值会减一  协议：标注上层协议类型，  数据链路层：以太网协议（以太网二型帧）     1byte=1字节=8位二进制  类型：标注上层协议类型，解封装时重要的参数  FCS：校验和（校验数据完整性的参数）运用SRC循环冗余算法 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/2301_80943978/article/details/135197036 

 一、云计算的基本概念 定义与内涵 云计算是一种基于互联网的计算模式，通过网络将大量的计算资源（如服务器、存储、应用软件、服务等）进行整合，以服务的形式提供给用户。 它实现了资源的虚拟化，使得用户无需直接管理和维护物理硬件设施，就能按需获取和使用计算能力，就像使用水电等公共资源一样便捷。 云计算涵盖了基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）等多种服务层次，满足不同用户的多样化需求。 核心技术支撑 虚拟化技术是云计算的基石，它将物理资源抽象为虚拟资源，提高资源利用率和灵活性，例如可在一台物理服务器上运行多个虚拟机，每个虚拟机都能独立运行操作系统和应用程序。 分布式存储技术通过将数据分散存储在多个节点上，确保数据的可靠性和高可用性，同时具备良好的扩展性，可轻松应对数据量的快速增长。 弹性计算技术能够根据用户的实际需求，快速自动地调整计算资源的分配，如在业务高峰期自动增加服务器实例，业务低谷期回收资源，节省成本。 与传统计算模式对比 传统计算模式下，企业需要自行购买、部署和维护硬件设备及软件系统，前期投资大、建设周期长；而云计算采用按需付费模式，降低了前期成本和运维成本，企业可将更多资金投入到核心业务创新中。 传统模式的资源利用率低，大量硬件资源可能处于闲置状态；云计算通过资源池化和动态分配，显著提高了资源利用率，减少资源浪费。 在应对业务快速变化和突发需求方面，传统计算模式的扩展能力有限且速度慢；云计算能够迅速提供所需资源，快速响应市场变化，增强企业竞争力。 服务模式详解 IaaS 为用户提供基础的计算、存储和网络等基础设施资源，用户可自行安装和管理操作系统、中间件和应用程序，具有高度的灵活性和控制权，如亚马逊的 EC2、阿里云的 ECS 等。 PaaS 提供了应用程序开发和部署的平台，包括操作系统、编程语言运行环境、数据库等，用户专注于应用开发，无需关心底层基础设施的管理和维护，如 Heroku、谷歌的 App Engine 等。 SaaS 则是直接向用户提供完整的软件应用，用户通过浏览器或客户端即可使用，无需进行本地安装和维护，如办公软件 Office 365、客户关系管理系统 Salesforce 等。 部署模型差异 公有云由第三方云服务提供商拥有和运营，面向公众开放，资源共享程度高，成本相对较低，适合中小企业和对成本敏感、需求灵活多变的用户，但在数据安全性和隐私方面可能存在一定风险。 私有云专为单个企业或组织构建，部署在企业内部数据中心或托管在第三方，数据安全性和隐私性强，可根据企业特定需求进行定制化配置，但建设和维护成本较高，适用于对安全性和合规性要求严格的大型企业。 混合云结合了公有云和私有云的优势，企业可将敏感数据和关键业务放在私有云，非关键业务或临时性业务需求放在公有云，实现资源的灵活调配和优化利用，兼具安全性和成本效益，是许多企业的理想选择。 二、云计算的关键特性 按需自助服务 用户能够通过云服务提供商的自助平台，根据自身业务需求，随时自主地获取所需的计算资源，如服务器实例、存储空间、网络带宽等，无需人工干预。 这种自助服务模式打破了传统 IT 资源获取的繁琐流程，大大缩短了资源交付时间，用户可以在几分钟甚至几秒钟内完成资源的申请和部署，快速响应业务变化。 同时，用户可以根据业务量的变化，灵活地调整资源的配置，如增加或减少 CPU 核心数、内存大小等，真正实现资源的按需使用，避免资源闲置和浪费，降低成本。 广泛的网络访问 云计算服务通过互联网进行访问，用户可以使用各种终端设备（如笔记本电脑、智能手机、平板电脑等），在任何有网络连接的地方，随时随地访问和使用云服务。 这种便捷的网络访问方式，打破了地域和时间的限制，使得企业员工能够远程办公、协同工作，提高工作效率和灵活性，促进了企业的全球化业务拓展和创新。 云服务提供商通过采用先进的网络技术（如内容分发网络 CDN、高速光纤网络等），确保用户在不同地区和网络环境下都能获得稳定、高速的服务体验，保障业务的连续性和可靠性。 资源池化 云计算将计算资源（如服务器、存储设备、网络带宽等）进行集中整合，形成一个庞大的资源池，通过虚拟化技术对资源进行抽象和分配，实现资源的共享和复用。 资源池化使得云服务提供商能够根据用户的需求，动态地分配和管理资源，提高资源利用率和灵活性，降低运营成本，同时也能够快速响应用户的资源请求，提供高效的服务。 为了确保资源池的高效运行和资源的合理分配，云服务提供商采用了先进的资源调度算法和管理系统，对资源的使用情况进行实时监控和优化，保障各个用户的服务质量和性能。 快速弹性扩展 云计算能够根据用户业务量的变化，快速自动地调整资源的分配和配置，实现弹性扩展和收缩。在业务高峰期，云服务提供商可以迅速为用户提供更多的计算资源，以满足业务需求；在业务低谷期，则回收闲置资源，降低成本。 这种快速弹性扩展能力，使得企业能够轻松应对突发的业务流量增长、季节性业务高峰等情况，无需提前过度投资硬件设备，提高了企业的应变能力和竞争力。 云服务提供商通过自动化的资源管理系统和弹性伸缩策略，实现了资源的快速调配和优化，确保在资源扩展和收缩过程中，业务的连续性和稳定性不受影响，用户体验不受损害。 可计量的服务 云计算采用了精确的计量技术，对用户使用的各种计算资源（如 CPU 时间、内存使用量、存储容量、网络流量等）进行实时监测和计量，并按照使用量向用户收取费用。 这种可计量的服务模式，使得用户能够清楚地了解自己的资源使用情况和费用支出，便于进行成本控制和预算管理，避免了传统 IT 模式下资源使用的不透明和成本超支问题。 云服务提供商通过提供详细的计费报告和资源使用分析工具，帮助用户优化资源配置，提高资源利用率，降低成本，同时也为用户提供了更多的选择和灵活性，用户可以根据自己的业务需求和预算，选择合适的资源套餐和计费方式。 三、云计算的主要优势 成本效益显著 降低硬件采购成本，企业无需购买昂贵的服务器、存储设备等硬件设施，避免了硬件设备的折旧和更新换代成本，只需根据实际使用情况向云服务提供商支付相应的费用，节省了大量的前期投资。 减少运维人力成本，云服务提供商负责基础设施的管理和维护，企业无需配备专业的 IT 运维团队，降低了人力成本和培训成本，同时也减少了因运维失误导致的业务风险和损失。 提高资源利用率，云计算通过资源池化和弹性扩展技术，实现了资源的动态分配和共享复用，避免了传统 IT 模式下资源闲置浪费的问题，提高了资源利用率，进一步降低了单位资源的使用成本。 按需付费模式使企业能够根据业务发展情况灵活调整资源使用量和费用支出，避免了资源过度配置或不足的情况，实现成本的精准控制，提高了企业的资金使用效率。 云服务提供商通常具有规模经济优势，能够通过大规模采购硬件设备、优化数据中心运营等方式降低成本，并将部分成本优势传递给用户，使得用户能够以更低的价格获得高质量的 IT 服务。 强大的灵活性与可扩展性 云计算支持多种服务模式（IaaS、PaaS、SaaS）和部署模型（公有云、私有云、混合云），企业可以根据自身业务需求和技术能力，选择最适合的云计算方案，实现个性化的 IT 架构搭建和应用部署。 能够快速响应业务变化，企业在业务增长或业务需求发生变化时，可以通过云服务提供商的自助平台或自动化工具，轻松地增加或减少计算资源、扩展或收缩应用系统的规模，无需进行复杂的硬件设备升级和系统架构调整。 支持新型业务模式和创新应用的快速开发与部署，企业可以利用云计算平台提供的丰富的开发工具、API 接口和应用组件，快速搭建和上线新的业务应用，缩短产品上市时间，抢占市场先机，促进企业的业务创新和发展。 可以方便地与现有 IT 系统进行集成和整合，企业在采用云计算的过程中，可以通过云平台提供的各种集成工具和接口，将云计算服务与企业内部的传统 IT 系统（如企业资源规划 ERP、客户关系管理 CRM 等）进行无缝对接，实现数据和业务流程的互联互通，保护企业的现有 IT 投资。 云服务提供商不断推出新的服务和功能，企业可以根据自身业务发展需求，及时选用这些新的服务和功能，不断优化和提升自身的 IT 能力和业务竞争力，无需担心技术过时和淘汰的问题。 提升业务敏捷性 加速应用开发和部署周期，云计算平台提供了丰富的开发工具、预配置的应用环境和自动化的部署流程，开发团队可以专注于业务逻辑的实现，无需花费大量时间搭建和配置开发环境，大大缩短了应用开发和上线的时间，提高了企业的创新速度。 促进团队协作和沟通效率，基于云计算的办公软件和协作平台，使得企业员工可以随时随地进行文档协作、项目管理、在线会议等工作，打破了时间和空间的限制，提高了团队的协作效率和沟通效果，加速了业务决策和执行的速度。 快速响应市场变化和客户需求，企业可以利用云计算的弹性扩展和快速部署能力，及时调整业务策略和产品功能，快速推出满足市场变化和客户需求的新产品和新服务，提高客户满意度和市场占有率。 支持企业进行业务创新和试验，云计算的低成本和灵活性使得企业可以尝试一些新的业务模式、技术应用和营销手段，无需承担过高的风险和成本，如果试验成功则可以快速推广和扩大规模，如果失败则可以及时停止，避免了对企业核心业务的影响，降低了企业的创新风险。 提升企业的整体运营效率，云计算通过整合企业的 IT 资源、优化业务流程和提高团队协作效率，使得企业的各项业务能够更加顺畅地运行，减少了业务流程中的瓶颈和延误，提高了企业的生产效率和运营效益，增强了企业的市场竞争力。 数据安全性与可靠性保障 云服务提供商采用了多层次的数据安全防护措施，包括数据加密技术，对用户数据在传输和存储过程中进行加密处理，防止数据被窃取和篡改；访问控制机制，通过身份认证、授权管理等手段，确保只有合法用户能够访问相应的数据和资源，防止数据泄露和非法访问。 具备高可靠性的数据备份和恢复策略，云服务提供商通常会在多个地理位置的数据中心对用户数据进行备份，以防止因硬件故障、自然灾害、人为错误等原因导致的数据丢失，并能够在数据发生丢失或损坏时，快速地进行数据恢复，保障业务的连续性。 提供安全的网络环境，云服务提供商通过部署防火墙、入侵检测系统、DDoS 攻击防护等网络安全设备和技术，对云平台进行实时监控和防护，防止网络攻击和恶意流量对用户数据和应用的影响，确保云平台的网络安全稳定。 符合严格的安全标准和法规合规要求，许多云服务提供商通过了国际和国内的各种安全认证（如 ISO 27001、SOC 2 等），并遵循相关的法律法规（如 GDPR、CCPA 等），保障用户数据的安全性和隐私性，企业在使用云计算服务时，可以借助云服务提供商的专业安全能力，满足自身业务的安全合规需求。 云服务提供商拥有专业的安全团队和应急响应机制，能够及时发现和处理安全漏洞和安全事件，对安全威胁进行快速响应和处置，降低安全事件对用户业务的影响，为用户提供可靠的安全保障。 促进全球协作与业务拓展 打破地域限制，云计算使得企业员工、合作伙伴和客户可以在全球范围内通过互联网访问和使用企业的应用系统和数据资源，实现了全球范围内的信息共享和业务协作，促进了企业的国际化业务拓展和跨国团队合作。 便于企业在全球范围内快速部署业务应用和服务，企业可以利用云服务提供商在全球各地的数据中心和网络节点，将业务应用快速部署到目标市场，降低了跨国业务运营的技术门槛和成本，提高了企业的市场响应速度和业务拓展能力。 支持多语言和多地区的业务运营需求，云服务提供商的平台和应用通常具备多语言支持能力，企业可以根据不同地区和国家的语言文化特点，定制化开发和部署本地化的业务应用，满足当地用户的需求，提高企业的全球市场适应性和竞争力。 促进全球供应链的协同管理，通过云计算平台，企业可以与全球各地的供应商、合作伙伴进行实时的信息交互和业务协同，实现供应链的可视化管理和优化，提高供应链的效率和灵活性，降低供应链成本，增强企业在全球供应链中的竞争力。 有利于企业开展全球化的市场营销和客户服务，企业可以利用云计算平台的大数据分析能力和营销自动化工具，对全球市场和客户进行精准的市场分析和营销推广，提供个性化的客户服务，提高客户满意度和忠诚度，拓展全球客户市场。 四、云计算的应用领域 企业资源规划（ERP）与办公自动化 基于云计算的 ERP 系统，企业无需在本地部署复杂的硬件和软件设施，只需通过浏览器登录云平台，即可随时随地访问和管理企业的财务、采购、生产、销售、人力资源等核心业务流程，实现企业资源的集中化管理和协同运作。 办公自动化软件（如文档编辑、电子表格、演示文稿等）在云端的应用，使得企业员工可以在线协作编辑文档、实时共享文件资料、进行远程会议和沟通交流，提高了办公效率和团队协作能力，降低了企业的办公成本和沟通成本。 云 ERP 系统和办公自动化软件的集成应用，实现了企业业务流程和办公流程的无缝对接，数据的实时共享和交互，减少了人工数据录入和传递的错误，提高了数据的准确性和及时性，为企业的决策提供了更加准确的数据支持。 云服务提供商可以根据企业的行业特点和业务需求，为企业提供定制化的 ERP 和办公自动化解决方案，满足不同企业的个性化需求，同时还能够快速响应企业业务变化和升级需求，通过在线更新和升级软件功能，保持企业 IT 系统的先进性和适应性。 利用云计算的大数据分析功能，企业可以对 ERP 系统和办公自动化软件中产生的大量数据进行深入挖掘和分析，发现潜在的业务问题和市场机会，优化业务流程和决策制定，提高企业的运营管理水平和市场竞争力。 客户关系管理（CRM） 云 CRM 系统帮助企业集中管理客户信息，包括客户基本资料、购买历史、沟通记录等，实现客户信息的统一存储和共享，方便企业各部门随时了解客户情况，提供更加个性化的客户服务，提高客户满意度和忠诚度。 支持销售团队的日常工作，如客户线索管理、销售机会跟进、销售预测等，通过云计算的移动性和实时性，销售人员可以在外出拜访客户时，通过手机或平板电脑随时随地访问 CRM 系统，更新客户信息和销售进展，及时获取上级的指导和支持，提高销售效率和业绩。 提供市场营销自动化功能，企业可以利用云 CRM 系统进行市场活动策划、目标客户群体细分、营销邮件发送等活动，并对营销活动的效果进行实时跟踪和分析，优化营销策略和投资回报率，精准地获取潜在客户，促进企业业务增长。 云 CRM 系统的社交化功能，使得企业能够整合社交媒体平台上的客户数据和互动信息，深入了解客户的社交行为和需求偏好，更好地进行客户关系维护和品牌推广，拓展客户市场和业务渠道。 通过与其他企业应用系统（如 ERP、客服系统等）的集成，云 CRM 系统实现了企业前后端业务流程的无缝衔接，数据的双向流通和共享，提高了企业整体的运营效率和客户响应速度，为客户提供更加连贯和优质的服务体验。 电子商务与在线零售 云计算为电子商务平台提供了强大的计算能力和存储资源，支持海量商品信息的存储和管理、高并发的用户访问和交易处理，确保平台在促销活动、节假日等高峰时期的稳定运行，提升用户购物体验。 利用云计算的弹性扩展能力，电子商务企业可以根据业务量的变化，快速调整服务器资源和带宽资源，灵活应对业务增长和流量波动，避免因资源不足导致的网站卡顿、交易失败等问题，同时也降低了企业的硬件采购和运维成本。 云平台提供的大数据分析服务，帮助电子商务企业深入了解消费者的购物行为、偏好和需求，进行精准的商品推荐、个性化营销和价格优化，提高客户的购买转化率和复购率，增加企业的销售额和利润。 电子商务企业可以借助云计算的全球网络覆盖和多地区部署能力，快速将业务拓展到全球市场，为不同地区的消费者提供本地化的购物体验，包括语言支持、货币结算、物流配送等，降低跨国业务运营的技术门槛和成本，提升企业的国际竞争力。 云平台还支持电子商务企业与各类第三方支付机构、物流配送公司等进行深度集成，实现支付流程的安全便捷和物流信息的实时跟踪，确保订单的顺利交付和客户的满意度。同时，利用云计算的人工智能和机器学习技术，能够对交易数据进行实时监测和分析，及时发现并防范欺诈行为，保障企业和消费者的权益，为电子商务业务的健康发展提供坚实的技术保障。  五、云计算面临的挑战与应对策略 1.数据安全与隐私问题 挑战：用户数据集中存放在云服务提供商的数据中心，面临数据泄露、篡改、丢失等风险。云服务提供商可能因技术漏洞、内部人员违规操作或遭受外部攻击，导致用户敏感信息曝光，引发严重的隐私危机，影响用户对云计算的信任。 应对策略：云服务提供商应加强数据加密技术的应用，在数据传输和存储过程中采用高强度的加密算法，确保数据的机密性。建立严格的访问控制机制，基于用户身份、角色和权限进行精细的访问管理，防止未经授权的访问。同时，定期进行安全审计和漏洞扫描，及时发现并修复潜在的安全隐患。企业用户在选择云服务提供商时，应重点考察其安全防护措施和安全认证情况，签订详细的安全协议，明确双方的数据安全责任。 网络延迟与性能优化 挑战：对于一些对实时性要求较高的应用（如在线游戏、视频直播、金融交易等），云计算可能会因网络延迟问题影响用户体验。数据传输距离、网络拥塞、云服务提供商的网络架构等因素都可能导致数据传输速度变慢，响应时间延长，降低应用的性能和可用性。 应对策略：云服务提供商可以通过优化数据中心的分布，在全球各地建立更多的边缘数据中心，将计算资源靠近用户，减少数据传输距离，降低网络延迟。采用内容分发网络（CDN）技术，将常用的数据和内容缓存到离用户更近的节点，加速数据的传输和访问。此外，不断升级网络基础设施，提高网络带宽和传输速度，采用先进的网络优化算法，对网络流量进行智能调度和管理，确保关键应用的网络性能。 服务可靠性与中断风险 挑战：尽管云服务提供商通常具备高可靠性的架构设计，但仍可能因硬件故障、软件漏洞、自然灾害、电力中断等原因导致服务中断。服务中断不仅会影响企业的正常业务运营，还可能造成经济损失和声誉损害，尤其对于那些依赖云计算的关键业务系统来说，风险更为突出。 应对策略：云服务提供商应构建冗余的硬件架构和备份系统，采用分布式存储和多副本技术，确保数据的持久性和可用性。建立完善的灾难恢复计划，定期进行灾难恢复演练，确保在发生故障或灾难时能够快速切换到备用系统，保障服务的连续性。同时，向用户提供透明的服务状态监控信息和故障通知机制，让用户及时了解服务的运行情况，并采取相应的应对措施。企业用户也可以通过采用多云策略，将业务分布在多个云服务提供商上，降低因单一云平台故障而导致的业务中断风险。 供应商锁定问题 挑战：企业在使用云计算服务过程中，可能会因依赖特定云服务提供商的技术架构、接口和工具，而面临供应商锁定的困境。当企业想要更换云服务提供商或采用混合云策略时，可能会遇到数据迁移困难、应用兼容性问题、成本过高等障碍，限制了企业的灵活性和选择空间。 应对策略：企业在选择云服务提供商时，应优先考虑采用开放标准和开源技术的平台，确保数据和应用的可移植性。在应用开发过程中，遵循行业最佳实践和通用的架构设计原则，减少对特定云服务提供商专有技术的依赖。同时，定期评估云服务提供商的服务质量和成本效益，与供应商保持良好的沟通和合作关系，争取在合同中明确数据迁移和服务退出的条款和条件，以便在必要时能够顺利切换供应商或调整云计算策略。 法律法规与合规性风险 挑战：云计算的跨地域特性使得企业在使用云服务时，需要面对不同国家和地区复杂多变的法律法规和合规要求。例如，数据隐私保护法规、行业监管规定、税收政策等方面的差异，可能导致企业在数据存储、处理和传输过程中面临合规风险，一旦违反相关法律法规，企业可能会面临巨额罚款、法律诉讼等严重后果。 应对策略：云服务提供商应密切关注全球各地的法律法规变化，建立合规管理体系，确保自身的服务符合相关法规要求，并向用户提供合规性保障和指导。企业用户在使用云计算服务前，应充分了解所在行业和业务涉及地区的法律法规，对云服务提供商的合规能力进行评估，选择能够满足自身合规需求的供应商。同时，企业应加强内部的合规管理和培训，建立健全的数据治理机制，确保在云计算环境下的数据处理活动合法合规。 六、云计算的未来发展趋势 混合云与多云架构的普及 随着企业对云计算应用的深入，单一的公有云或私有云架构难以完全满足企业复杂的业务需求和安全要求。未来，混合云将成为主流趋势，企业会更加灵活地将核心业务和敏感数据部署在私有云，而将非关键业务和弹性需求放在公有云，实现资源的最优配置和业务的敏捷性。 多云策略也将得到更广泛的应用，企业通过与多个云服务提供商合作，利用不同云平台的优势，避免供应商锁定，提高业务的可靠性和灵活性。同时，云管理平台和工具将不断发展，帮助企业更方便地管理和协调多个云环境，实现无缝的跨云资源调度和应用部署。 人工智能与云计算的深度融合 人工智能技术（如机器学习、深度学习、自然语言处理等）将与云计算紧密结合，云平台将为人工智能应用提供强大的计算能力和海量的数据存储，加速人工智能模型的训练和推理过程。 基于云计算的人工智能服务将更加普及，企业无需自行搭建复杂的人工智能基础设施，即可通过云服务轻松应用人工智能技术，实现智能客服、智能营销、智能预测等功能，提升业务的智能化水平和竞争力。 人工智能还将用于优化云计算资源的管理和调度，通过智能算法实现自动的资源分配、性能优化和故障预测，提高云计算平台的运营效率和可靠性。 边缘计算与云计算的协同发展 随着物联网设备的大量增加和对实时性要求较高的应用场景（如工业自动化、智能交通、远程医疗等）的出现，边缘计算将与云计算相辅相成。边缘计算将计算和数据存储靠近数据源或用户端，减少数据传输延迟，提高响应速度，而云计算则负责处理大规模的数据汇总、分析和复杂的业务逻辑。 未来，云服务提供商将构建更加完善的边缘计算架构，实现边缘节点与云中心的高效协同，提供统一的管理和调度平台，让企业能够更加灵活地在边缘和云端部署应用，满足不同场景下的业务需求。 无服务器计算的兴起 无服务器计算（Serverless Computing）将逐渐成为云计算的重要组成部分，开发人员无需关心服务器的配置和管理，只需专注于编写代码和业务逻辑。云服务提供商将根据应用的实际运行情况自动分配和管理计算资源，实现真正的按需计费，进一步降低企业的运营成本和开发门槛。 无服务器架构将在事件驱动型应用、微服务架构等领域得到广泛应用，加速应用的开发和部署速度，提高资源利用率，使得企业能够更加敏捷地响应市场变化和用户需求。 绿色云计算的发展 随着全球对环境保护和可持续发展的关注度不断提高，绿色云计算将成为未来的重要发展方向。云服务提供商将致力于降低数据中心的能耗，采用更加高效的服务器硬件、冷却技术和能源管理系统，提高能源利用效率。 同时，通过优化数据中心的选址和布局，利用可再生能源（如太阳能、风能等）为数据中心供电，减少对传统能源的依赖，降低碳排放，实现云计算产业的绿色发展，为企业和社会创造更大的环境价值。 七、企业如何成功应用云计算 明确业务需求与目标 企业在采用云计算之前，应深入分析自身的业务需求和目标，确定哪些业务流程和应用适合迁移到云端，以及期望通过云计算实现什么样的业务价值，如降低成本、提高效率、加速创新、拓展市场等。 对企业现有的 IT 基础设施和应用系统进行全面评估，了解其技术架构、性能瓶颈、数据存储和管理方式等情况，以便更好地规划云计算的应用场景和迁移策略，确保云计算的应用能够与企业的整体业务战略相契合。 选择合适的云服务提供商 根据企业的业务需求、预算、安全要求和合规性标准，选择具有良好声誉、可靠技术实力和丰富行业经验的云服务提供商。评估云服务提供商的服务质量，包括可用性、性能、可靠性、安全性等方面，参考其客户评价和行业口碑。 考虑云服务提供商的服务范围和产品特点，是否能够提供满足企业需求的各种云计算服务模式（IaaS、PaaS、SaaS）和部署模型（公有云、私有云、混合云），以及其是否具备灵活的定价策略和良好的客户支持服务，确保在使用云计算过程中能够得到及时的技术支持和问题解决。 制定详细的迁移计划与策略 在进行应用和数据迁移到云端之前，制定详细的迁移计划，包括迁移的顺序、时间表、风险评估和应对措施等。对于复杂的应用系统，建议采用渐进式迁移策略，先迁移非关键业务或相对独立的模块，积累经验后再逐步迁移核心业务系统，降低迁移风险。 在迁移过程中，充分考虑数据的完整性和一致性，进行数据备份和验证，确保数据在迁移前后的准确性和可用性。同时，对应用进行必要的优化和适配，以充分利用云计算的优势，如弹性扩展、性能优化等，提高应用在云端的运行效率和稳定性。 加强安全与风险管理 建立完善的云计算安全管理体系，包括数据安全、网络安全、应用安全和身份管理等方面。制定严格的数据访问控制策略，对敏感数据进行加密存储和传输，定期进行安全审计和漏洞扫描，及时发现和解决潜在的安全问题。 加强对云服务提供商的安全监督和评估，确保其安全措施符合企业的要求和行业标准。同时，制定应对安全事件的应急预案，提高企业在面对安全威胁时的应急响应能力和恢复能力，降低安全风险对企业业务的影响。 培养云计算专业人才 云计算的应用需要企业具备一定的专业技术人才，包括云计算架构师、管理员、开发人员等。企业应加强对内部员工的云计算培训，提高员工对云计算技术的理解和应用能力，使其能够熟练掌握云计算平台的管理和开发工具，适应云计算环境下的工作方式和业务流程。 吸引外部云计算专业人才加入企业，充实企业的技术团队，为企业的云计算应用提供技术支持和创新动力。同时，鼓励员工参与云计算相关的行业交流和认证考试，不断提升员工的专业水平和综合素质，推动企业云计算应用的深入发展。 ————————————————                              你敢抄袭？自己写，要做个好孩子哦！！！                          原文链接：https://blog.csdn.net/hjxxlsx/article/details/144506771 

容器的介绍容器化技术，它是一种虚拟化技术，用于在计算机系统中隔离和运行应用程序。容器将应用程序及其所有依赖项打包到一个独立的、可移植的环境中，使其能够在不同的计算机或操作系统上运行。容器的特点：隔离性、轻量级、可移植性、弹性伸缩、生态系统。目前最流行的容器化技术是Docker，它提供了一个开放的平台，用于构建、分发和运行容器。除了Docker，还有其他容器化技术，如Kubernetes、Podman、Containerd等。容器的精髓在于镜像，而docker是容器镜像标准的制定者，因此，学习容器是绕不开docker的。Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器Docker的技术架构Docker 客户端（Client）： Docker 客户端是用户与 Docker 交互的命令行工具或图形界面工具。用户可以使用 Docker 客户端发送命令和指令，例如构建镜像、创建容器、启动容器等。Docker 客户端与 Docker 主机进行通信，通过 API 接口或者 Docker 配置文件进行交互。常见的 Docker 客户端包括 Docker CLI（命令行界面）和 Docker Dashboard（图形用户界面）。Docker 主机（Docker Host）： Docker 主机是安装和运行 Docker 引擎的物理或虚拟机器。它负责管理容器的创建、启动、停止和销毁等生命周期操作。Docker 主机上运行着 Docker 引擎，它接收来自 Docker 客户端的指令，并执行相应的操作。Docker 主机上可以同时运行多个容器，并提供了资源隔离、网络管理和存储管理等功能。镜像仓库（Registry）： 镜像仓库是用于存储和分发 Docker 镜像的中央仓库。镜像仓库允许用户上传、下载和共享镜像。当用户在 Docker 主机上创建镜像时，可以选择将镜像推送到镜像仓库中，以便其他人可以使用这个镜像。Docker Hub 是官方提供的公共镜像仓库，用户可以从中获取各种常用的镜像。除了 Docker Hub，还有一些私有和第三方的镜像仓库可供选择，例如 Harbor、Azure Container Registry 等。在整个架构中，Docker 客户端与 Docker 主机通过 API 接口进行通信，Docker 主机负责管理容器的运行和资源隔离。镜像仓库则是存储和分享镜像的中央仓库，用户可以从中拉取镜像或将自己创建的镜像推送至其中。这样，Docker 技术架构实现了应用程序的打包、分发和部署，提供了一种便捷、可移植和可扩展的容器化环境。容器的工作机制（Docker）Docker 客户端（Docker Client）：Docker 客户端是用户与 Docker 交互的命令行工具或 GUI 工具。它向 Docker 引擎发送指令，如拉取镜像、创建容器、启动容器等。Docker 引擎（Docker Engine）：Docker 引擎是 Docker 的核心组件，负责管理容器的生命周期，包括创建、启动、停止、删除等操作。它还提供了一组 API 接口和命令行工具，供用户与 Docker 进行交互。容器（Container）：容器是从容器镜像创建的运行实例。它是一个独立的、隔离的执行环境，其中应用程序可以在其中运行。容器具有自己的文件系统、网络和进程空间，但与主机系统是隔离的。Docker 客户端和 Docker 引擎是分离的两个组件，Docker 客户端发送指令给 Docker 引擎，Docker 引擎执行指令并管理容器的生命周期。容器则是从容器镜像创建的运行实例，它具有隔离性、资源管理和网络管理等特性，使得应用程序可以在一个独立且可移植的环境中运行。容器的关键技术 - NamespaceNamespace是Linux内核对系统资源进行隔离和虚拟化的特性，这些系统资源包括：PID ：PID 命名空间提供了进程 ID 的隔离。User：User 命名空间提供了用户和用户组的隔离。UTS：UTS 命名空间提供了主机名和域名的隔离。IPC：IPC 命名空间提供了进程间通信（IPC）资源的隔离，如共享内存、信号量和消息队列等。Net：Net 命名空间提供了网络资源的隔离，包括网络接口、IP 地址、路由表和网络命名空间等。Mnt：Mnt 命名空间提供了文件系统挂载点的隔离。Namespace隔离说明以交互模式启动一个centos容器，并在其中运行/bin/bash程序。执行ps命令查看到“/bin/bash”是PID=1的进程，即docker将其隔离于宿主机中的其他进程[root@localhost ~]# docker run -it centos /bin/bash [root@24b87937f13d /]# ps axf PID TTY STAT TIME COMMAND 1 pts/0 Ss 0:00 /bin/bash 14 pts/0 R+ 0:00 ps axf打开另一个终端，使用docker inspect查看容器进程在宿主机上的真实PID。实际上，该容器上运行的”/bin/bash”在宿主机上是PID=96745的进程[root@localhost ~]# docker inspect 24b87937f13d | grep Pid "Pid": 96745, "PidMode": "", "PidsLimit": 0,容器的关键技术 - CgroupCgroups：Linux Control Group作用：限制一个进程组对系统资源的使用上限，包括CPU、内存、Block I/O等Cgroups还能设置进程优先级，对进程进行挂起和恢复等操作原理：将一组进程放在一个Cgroup中，通过给这个Cgroup分配指定的可用资源，达到控制这一组进程可用资源的目的实现：在Linux中，Cgroups以文件和目录的方式组织在操作系统的/sys/fs/Cgroup路径下。该路径中所有的资源种类均可被Cgroup限制Docker环境搭建操作系统内存处理器硬盘网络Centos 8 Stream4 GB150GBNAT1）安装基础软件包[root@docker ~]# yum install -y vim net-tools bash-completion yum-utils # 或者退出重新登录，为了自动补全 [root@docker ~]# bash 2）下载docker-ce repo文件[root@docker ~]# yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo [root@docker ~]# cd /etc/yum.repos.d/ [root@docker yum.repos.d]# ls CentOS-Stream-AppStream.repo CentOS-Stream-BaseOS.repo CentOS-Stream-Debuginfo.repo CentOS-Stream-Extras-common.repo CentOS-Stream-Extras.repo CentOS-Stream-HighAvailability.repo CentOS-Stream-Media.repo CentOS-Stream-NFV.repo CentOS-Stream-PowerTools.repo CentOS-Stream-RealTime.repo CentOS-Stream-ResilientStorage.repo CentOS-Stream-Sources.repo docker-ce.repo3）安装# 查看docker版本 [root@docker ~]# yum list docker-ce --showduplicates | sort -r # 默认安装最新版 [root@docker ~]# yum install -y docker-ce # 安装指定版本 [root@docker ~]# yum install -y docker-ce-20.10.22 docker-ce-cli-20.10.224）启动# 查看docker版本 [root@docker ~]# docker -v Docker version 24.0.6, build ed223bc #开启docker服务、开机自启、查看状态 [root@docker ~]# systemctl enable docker.service Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service. [root@docker ~]# systemctl start docker.service [root@docker ~]# systemctl status docker.service ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; > Active: active (running) since Sun 2023-09-17 17:20:23 CST; 5s ago Docs: https://docs.docker.com Main PID: 12240 (dockerd) Tasks: 7 Memory: 28.4M CGroup: /system.slice/docker.service └─12240 /usr/bin/dockerd -H fd:// --containerd=/run/conta> Sep 17 17:20:22 docker systemd[1]: Starting Docker Application Conta> Sep 17 17:20:22 docker dockerd[12240]: time="2023-09-17T17:20:22.760> Sep 17 17:20:22 docker dockerd[12240]: time="2023-09-17T17:20:22.770> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.159> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.241> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.250> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.250> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.263> Sep 17 17:20:23 docker systemd[1]: Started Docker Application Contai>5）配置镜像加速器以阿里云镜像加速器为例[root@docker ~]# mkdir -p /etc/docker [root@docker ~]# tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } EOF { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } [root@docker ~]# cat /etc/docker/daemon.json { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } # 重新加载配置文件 [root@docker ~]# systemctl daemon-reload # 重新启动docker服务 [root@docker ~]# systemctl restart docker.service # 标准的完整名称 服务器 仓库/分类 镜像 版本 registry.cn-hangzhou.aliyuncs.com/cloudcs/centos:latest # 版本默认情况下，如果不指定，那么默认为 latestDocker基本操作# 镜像的下载 [root@docker ~]# docker pull mysql # 镜像重命名 [root@docker ~]# docker tag mysql:latest mysql:666 # 镜像的删除 [root@docker ~]# docker rmi mysql:latest # 镜像历史信息 [root@docker ~]# docker history mysql:latest # 镜像保存 [root@docker ~]# docker save mysql alpine > /tmp/all.tar # 镜像导入 [root@docker ~]# docker load -i /tmp/all.tar尝试运行一个容器[root@docker ~]# docker run -tid --name d1 --restart always alpine 44936d56248d3c9657e502168ea91098b2caa69a065a7d712dd4d3048b3f508d # 查看正在运行容器 [root@docker ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 44936d56248d alpine "/bin/sh" 26 seconds ago Up 25 seconds d1 # 进入容器 [root@docker ~]# docker exec -ti d1 /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever / # exit感谢您阅读本文。我希望它能给您带来新的思考和启发，并为您的未来带来积极的影响。如果小伙伴们有任何问题或想法，请在下方留言，我会很乐意与您交流。谢谢各位小伙伴的支持。

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 在上一篇文章中，我们为适应用户对边缘设备管理的需求，设计实现了基于物模型的设备管理 API。在此基础上，我们完善了 DMI 数据面的能力，提供边缘端处理设备数据的多种方式，让 KubeEdge 能够更灵活、标准化的管理边缘设备。本篇文章是系列文章的第二篇，将详细介绍v1.15.0版本在 DMI 数据面的一些工作。DMI 数据面能力支持 在1.12版本中，KubeEdge 设计了设备管理框架——DMI。DMI 框架提供了统一的设备管理相关接口，设备应用开发者和使用者可以通过实现 DMI 中的标准化接口完成设备管理，让边缘设备以微服务的形式提供服务，更加贴合云原生。➤ DMI 的架构图如下图所示：DMI 框架中一个重要的特性是设备管理面与设备数据面解耦。设备管理面基于 Device CRD 承载设备本身的生命周期管理，如图中黄色线条；设备数据面则让设备数据通过微服务的方式向数据消费者应用提供，拥有多种数据推送方式，如图中蓝色线条。DMI 设备管理面数据主要包括设备的元数据、设备属性、配置、生命周期等，其特点是相对比较稳定，创建后信息更新较少，这类数据会通过云边通道进行传递。设备数据面数据则主要为设备传感器采集到的设备数据，相比于管理面数据来说数据量较大，若通过云边通道传输可能会造成通道阻塞，影响集群正常功能。v1.15.0版本中 DMI 数据面功能得到完善，通过数据面能以多样化的方式推送设备数据，相比通过云边通道传输数据更加合理。  DMI 数据面能力支持 ➤ DMI 数据面系统架构如下图所示：在v1.15.0版本更新后，DMI 数据面支持如图中四种方式处理推送设备数据：1、推送至用户应用。按照 v1beta1 版本的 Device Instance API 定义，用户能够在 Device Instance 配置文件中配置 pushMethod 字段，以 HTTP 或者 MQTT 的方式定时将设备数据推送到用户应用中。2、推送至用户数据库。最新版本的 KubeEdge DMI 内置 InfluxDB、Redis、TDengine、MySQL 数据库的数据推送方式，用户能够在 Device Instance 配置文件中 dbMethod 字段设置相应数据库的参数，将设备数据定时传入数据库。3、推送至云端。用户能够设置 Device Instance 配置文件中 reportToCloud 字段决定是否将设备数据推送至云端。4、用户能够通过 Mapper 提供的 RESTful API 主动拉取设备数据。以下是一个使用 DMI 数据面能力处理设备数据的 Device Instance 配置文件示例：apiVersion: devices.kubeedge.io/v1beta1 kind:Device ... spec: properties: -name:temp collectCycle:10000 # The frequency of reporting data to the cloud. once every 10 seconds reportCycle:10000 # The frequency of data push to user applications or databases. reportToCloud:true # Device data will be reported to cloud desired: value:"100" pushMethod: mqtt: # define the MQTT config to push device data to user app address:tcp://127.0.0.1:1883 topic:temp qos:0 retained:false dbMethod: influxdb2: # define the influx database config to push device data to user database influxdb2ClientConfig: url:http://127.0.0.1:8086 org:test-org bucket:test-bucket influxdb2DataConfig: measurement:stat tag: unit:temperature fieldKey: devicetest在示例文件中，用户可以通过 reportToCloud 字段定义 Mapper 是否将设备数据推送至云端；此外，pushmethod.mqtt 字段定义了 Mapper 向用户应用推送的配置信息，示例中表示 Mapper 会定时以 MQTT 协议的方式向 127.0.0.1:1883 地址的用户应用推送设备数据；pushmethod.dbMethod 字段定义了 Mapper 向用户数据库推送的配置信息，示例中表示 Mapper 会定时向 127.0.0.1:8086 地址的 InfluxDB 数据库推送设备数据。基于 DMI 数据面的能力，用户只需在 Device Instance 配置文件中定义相关字段，即可使用多种方式处理采集到的设备数据，有效降低了云边通道阻塞的风险。DMI 提供的功能接口最终是由设备管理插件 Mapper 来承载的。Mapper 北向需要实现 DMI 管理接口向 KubeEdge 完成自身的注册以及设备管理。对于用户来说，独立对接 DMI 接口实现自定义的 Mapper 使用门槛依然较高，因此我们在v1.15.0版本中推出 Mapper 开发框架 Mapper Framework，能够使用简单的命令自动生成一个 Mapper 工程供用户使用，有效降低用户上手的难度。在本系列的下一篇文章中，我们会对 Mapper Framework 的架构与使用方法进行详细介绍。【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.12版本[1]现已发布，本版本包含下列新增特性：应用级故障迁移功能增强（新增状态中继机制，适用于大数据处理程序高可用场景，如 Flink）单集群应用迁移能力增强（适用于单集群存量应用迁移）Karmada Operator 高可用部署能力支持OverridePolicy 支持局部修改结构化字段值新特性概览▶  应用级故障迁移功能增强在之前的版本中，Karmada 提供了基本的应用级故障迁移能力，能够通过应用的健康状态或自定义的故障等条件触发应用迁移。为了满足有状态应用在故障迁移过程中保留其运行状态的需求，Karmada 在 v1.12 版本新增了应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在PropagationPolicy/ClusterPropagationPolicy API 中的.spec.failover.application 下引入了一个新的StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略StatePreservation 包含了一系列StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。每个 Flink 作业在提交到 Flink 集群时都会被分配一个jobID。当作业发生故障时，Flink 应用可以利用jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:foo spec: #... failover: application: decisionConditions: tolerationSeconds:60 purgeMode:Immediately statePreservation: rules: -aliasLabelName:application.karmada.io/failover-jobid jsonPath:"{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如application.karmada.io/failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置initialSavepointPath 指示从save point 启动。Flink 应用根据initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力基于 FlinkDeployment 打造，但广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现故障迁移的状态中继。此功能需要启用 StatefulFailoverInjection 特性开关。StatefulFailoverInjection 目前处于 Alpha 阶段，默认情况下是关闭的。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为Immediately，即故障应用需立即删除然后再创建新应用，确保数据一致性。▶  单集群应用迁移能力增强在用户将业务从单集群迁移至多集群的过程中，如果资源已经被迁移到 Karmada 控制面，那么当控制面中的资源模板被删除时，成员集群中的资源也会随之删除。但在某些场景，用户希望能够保留成员集群中的资源。例如，作为管理员，在工作负载迁移过程中可能遇到意外情况（如云平台无法发布应用程序或 Pod 异常）， 需要回滚机制立刻恢复到迁移之前的状态，以便快速止损。在 v1.12 版本，社区在PropagationPolicy/ClusterPropagationPolicy API 中引入了PreserveResourcesOnDeletion 字段，用于定义当控制面中的资源模板被删除时成员集群上资源的保留行为，如果设置为true，则成员集群上的资源将被保留。结合此字段，一旦用户在迁移过程中发现异常，可以快速执行回滚操作并保留成员集群中原有的资源，整个迁移回滚过程更加安全可控。使用该字段请注意以下两点：该配置对所有成员集群统一生效，不会仅针对部分集群进行选择性控制。当 Policy 被删除时，资源模板及已分发的成员集群资源将保持不变，除非被显式删除。以 PropagationPolicy 为例，用户在删除 Karmada 控制面资源模板时，可以配置如下 PropagationPolicy 来保留成员集群的资源：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:nginx-pp spec: conflictResolution:Overwrite preserveResourcesOnDeletion:true# 资源模板删除后，成员集群资源依然保留 placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:nginx -apiVersion:v1 kind:Service name:nginx-svc更多有关安全回滚迁移的资料请参考：迁移操作如何回滚[2] 。▶  Karmada Operator 高可用部署能力支持作为社区维护的安装工具，Karmada-operator 可以用来部署和管理多个 Karmada 实例。为了更好地支持高可用部署方案，karmada-operator 在本版本实施了一系列针对性的改进和优化措施，包括：引入了对自定义 CA 证书的支持；支持连接外部 etcd；可通过 Secret 指定外部 etcd 客户端的凭据；可为 Karmada 组件指定卷和卷挂载；对外暴露 APISever 服务，用于服务发现。这些增强使得 karmada-operator 能够跨多个管理集群部署一个高度可用的 Karmada 控制平面，这些集群可以跨越不同的数据中心，从而满足故障恢复的诉求。上图是通过 Karmada-operator 构建的生产级高可用架构，在这个架构中，Karmada-operator 跨不同地理位置的数据中心部署多个 Karmada 控制面，并将它们连接到同一个外部 etcd 集群。这种设置不仅确保了跨数据中心的数据一致性，还简化了数据管理和维护工作。此外，借助 Karmada-operator 提供的 APIServer 服务暴露能力，结合 Ingress 对外提供统一的服务访问。同时，利用可配置的CA证书机制，保障了 Karmada 实例与外部服务间通信的安全性。此架构显著增强了系统对单个数据中心故障的抵御能力，最大限度地减少了因数据中心故障导致的服务中断风险，保证了业务连续性和用户体验的稳定性，符合严格的灾难恢复标准。▶  OverridePolicy 支持局部修改结构化字段值OverridePolicy 允许用户针对特定集群自定义资源的覆盖策略，确保资源可以在不同环境中灵活适配和优化。Kubernetes 资源如 Secrets 和 ConfigMaps 常常会用到结构化的字段值，如 ConfigMaps 的.data 利用 YAML 格式的结构化数据承载配置信息。在实际应用中，存在只需要修改其部分字段的情况，而且，当原始的结构化字段值复杂且内容繁多时，使用全覆盖将会大大增大 OverridePolicy 的配置难度。为了解决这一问题，并提高 OverridePolicy 在此类场景中的易用性，Karmada 引入了FieldOverrider 特性。FieldOverrider 支持对 JSON 和 YAML 格式的结构化字段值进行局部修改，即只添加或替换或删除所需的字段。这种方式简化了配置过程，提高了效率，同时减少了出错的可能性，使得资源管理更加直观和便捷。通过FieldOverrider，用户可以对结构化字段值进行更精细化地处理，适应多变的应用环境需求。下面以 ConfigMap 为例，用户可通过FieldOverrider 部分覆盖 ConfigMap 的.data 字段来实现集群间的差异化配置。# example-configmap apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: config.yaml: | app: database: port: 5432 ip: 127.0.0.1 name: example zone: zone1# example-overridepolicy apiVersion:policy.karmada.io/v1alpha1 kind:OverridePolicy metadata: name:example spec: resourceSelectors: -apiVersion:v1 kind:ConfigMap name:example-configmap overrideRules: -overriders: fieldOverrider: -fieldPath:/data/config.yaml yaml: -subPath:/app/database/port operator:replace# 支持add、remove和replace操作 value:"3306" targetCluster: clusterNames: -member1经过以上配置，集群 member1 中的 ConfigMap 将更新为：# example-configmap in member1 apiVersion: v1 kind: ConfigMap metadata: name: myconfigmap data: config.yaml: | app: database: port: 3306 # 更新了port ip: 127.0.0.1 name: example zone: zone1更多FieldOverrider 的用法请参考：FieldOverrider 使用指南[3]▶ 致谢贡献者Karmada v1.12 版本包含了来自 33 位贡献者的 253 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：@a7i@ahorine@anujagrawal699@B1f030@chaosi-zju@CharlesQQ@chaunceyjiang@husnialhamdani@iawia002@ipsum-0320@jabellard@jklaw90@KhalilSantana@LavredisG@liangyuanpeng@LivingCcj@MAVRICK-1@mohamedawnallah@mszacillo@RainbowMango@SataQiu@seanlaii@sophiefeifeifeiya@tiansuo114@wangxf1987@whitewindmills@wulemao@XiShanYongYe-Chang@xovoxy@yanfeng1992@yelshall@zach593@zhzhuang-zju参考资料[1]Karmada v1.12版本:cid:link_5[2]迁移操作如何回滚:cid:link_0[3]FieldOverrider 使用指南:cid:link_4【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_6 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评