1 整体介绍本参考实践，面向ISV伙伴提供深度优化使能套件，打造一体机、小集群两个场景的高性能、轻量化、安全算力底座。两种场景的适用范围如下： ●一体机算力底座：面向单一业务、软硬件预集成场景，如：辅助诊疗一体机、AI实训一体机等。 ●小集群算力底座：面向多业务混部、虚机/容器化部署、算力按需扩容场景，如：医院核心信息系统等。 2 小集群算力底座基于openFuyao+Ceph+基础加速特性提供小集群算力底座参考实践： 1、通过Ceph提供块存储和共享存储功能； 2、通过openFuyao提供虚机、容器的创建、删除和管理基础功能； 3、openFuyao和Ceph支持单台鲲鹏服务器起部，支持平滑扩容到2台或3台以上服务器； 4、集成基础加速特性的使用参考：包括虚机/容器绑核、毕昇JDK替换openJDK8、etcd组件Go编译、KAE硬加速、弹性内存等； 5、提供自动部署openFuyao、Ceph的能力。 2.1 整体架构在小集群场景下，传统“存算分离”架构面临成本高昂、管理面臃肿等缺陷。而小集群算力底座深度融合 openFuyao 算力调度与 Rook-Ceph 云原生分布式存储功能，依托鲲鹏 920 处理器打造openFuyao和Ceph组合的，开源生态的虚拟化、容器和分布式存储的小集群算力底座。在存储与管理方面，基于 Ceph 动态供给高性能块存储（RBD）与共享文件系统（CephFS），在保障 Pod 和虚拟机（KubeVirt）全生命周期高效 CRUD 与极速容灾重建的同时，原生集成 TEE 机密容器技术，利用硬件安全特性为核心数据与算法资产提供全方位的合规护航。在底层调优方面，通过静态 CPU 绑核、毕昇 JDK、Go 编译优化等加速特性，合理分配资源，消除混部干扰，释放鲲鹏服务器算力。 2.2 安装部署本参考实践基于以下版本配套验证: 软件版本说明 OS openEuler release 24.03 (LTS-SP1) 物理机OS，要求系统内核不低于5.11。 openFuyao 26.03 使用的Kubernetes版本为1.34.3 Ceph 19.2.3 分布式存储 snapshotter 8.2.1 CSI 快照组件 Velero 1.17.2 备份与恢复工具安装部署章节以单节点部署openFuyao+ceph为例给出参考步骤，所有操作在一台服务器进行，整体流程如下： 2.2.1 安装包及依赖获取 openFuyao：# envcheck工具： arm64：https://openfuyao.obs.cn-north-4.myhuaweicloud.com/openFuyao/env-check/releases/download/latest/bin/linux/arm64/envCheck amd64：https://openfuyao.obs.cn-north-4.myhuaweicloud.com/openFuyao/env-check/releases/download/latest/bin/linux/amd64/envCheck # envcheck配置文件： arm64：https://openfuyao.obs.cn-north-4.myhuaweicloud.com/openFuyao/env-check/releases/download/latest/bin/linux/arm64/config.json amd64：https://openfuyao.obs.cn-north-4.myhuaweicloud.com/openFuyao/env-check/releases/download/latest/bin/linux/amd64/config.json # 离线安装部署包构建： yum install tar pigz docker # 编辑/etc/docker/daemon.json文件 { "insecure-registries": [ "0.0.0.0/0" ] } systemctl restart docker curl -sfL https://openfuyao.obs.cn-north-4.myhuaweicloud.com/openFuyao/bkeadm/releases/download/1.2.2/download.sh | bash curl -O https://openfuyao.obs.cn-north-4.myhuaweicloud.com/openFuyao/version-config/Core-VersionConfig-v26.03.yaml rm -rf /bke && bke build -f Core-VersionConfig-v26.03.yaml -t bke.tar.gz # bke.tar.gz为引导节点的离线安装部署包 rook-ceph：# chart包 curl -kfsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash helm repo add rook https://charts.rook.io/release helm repo update helm pull rook/rook-ceph --version 1.19.2 # 获取rook-ceph-v1.19.2.tgz helm pull rook/rook-ceph-cluster --version 1.19.2 # 获取rook-ceph-cluster-v1.19.2.tgz # 镜像包 docker pull quay.io/cephcsi/ceph-csi-operator:v0.5.0 docker save quay.io/cephcsi/ceph-csi-operator:v0.5.0 | gzip > ceph-csi-operator-v0.5.0.tar.gz docker pull docker.io/rook/ceph:v1.19.2 docker save docker.io/rook/ceph:v1.19.2 | gzip > rook-ceph-v1.19.2.tar.gz docker pull quay.io/ceph/ceph:v19.2.3 docker save quay.io/ceph/ceph:v19.2.3 | gzip > ceph-ceph-v19.2.3.tar.gz docker pull quay.io/cephcsi/cephcsi:v3.16.1 docker save quay.io/cephcsi/cephcsi:v3.16.1 | gzip > cephcsi-v.16.1.tar.gz docker pull registry.k8s.io/sig-storage/csi-provisioner:v6.0.0 docker save registry.k8s.io/sig-storage/csi-provisioner:v6.0.0 | gzip > csi-provisioner-v6.0.0.tar.gz docker pull registry.k8s.io/sig-storage/csi-resizer:v2.0.0 docker save registry.k8s.io/sig-storage/csi-resizer:v2.0.0 | gzip > csi-resizer-v2.0.0.tar.gz docker pull registry.k8s.io/sig-storage/csi-attacher:v4.10.0 docker save registry.k8s.io/sig-storage/csi-attacher:v4.10.0 | gzip > csi-attacher-v4.10.0.tar.gz docker pull registry.k8s.io/sig-storage/csi-snapshotter:v8.4.0 docker save registry.k8s.io/sig-storage/csi-snapshotter:v8.4.0 | gzip > csi-snapshotter-v8.4.0.tar.gz docker pull registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.15.0 docker save registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.15.0 | gzip > csi-node-driver-registrar-v2.15.0.tar.gz 安装引导节点后系统会自动卸载docker，提前将Ceph所需镜像转成tar包，后续用ctr导入。后续引导集群、业务集群和ceph的安装也可使用脚本快捷部署：openFuyao&Ceph安装脚本 2.2.2 openFuyao引导集群创建安装前需确保“/”分区至少有50G可用空间。unset http_proxy https_proxy rm -rf /bke && tar zxvf bke.tar.gz -C / # 修改安装工具名称 ARCH=$(uname -m) case $ARCH in x86_64) ARCH="amd64";; aarch64) ARCH="arm64";; esac mv /usr/local/bin/bkeadm_linux_$ARCH /usr/local/bin/bke # 初始化引导节点 bke init 若安装过程中断，执行如下命令清理残留文件后重新安装。 bke reset --all --mount 2.2.3 openFuyao业务集群创建 1登录引导节点管理页面。默认：https://引导节点ip:30010，用户名：admin，初始密码：test@1234，首次登录后需要修改初始密码。 2创建业务集群。登录后点击新增集群进入集群创建页面，填写基本信息，Master信息，高级配置并通过校验后自动进行业务集群创建。 3登录业务集群管理面。开始集群创建后，可在Master节点用kubectl get pod -A 命令查看集群状态，待所有pod处于running或complete后，浏览器访问https://Master节点ip:31616。用户名：admin，初始密码：test@1234，首次登录后需修改密码。 2.2.4 业务集群接入Ceph存储 1准备裸盘。以1块nvme盘为例，假定磁盘在lsblk中的NAME是nvme1n1，清理磁盘，确保磁盘能被Ceph使用。# 卸载网络块设备 (Network Block Device) 内核模块，防止残留的虚拟块设备挂载或占用磁盘资源。 rmmod nbd # 强制 (-f) 并清除 (-a) 盘上的所有文件系统、RAID 或分区表签名，让系统不再识别旧的文件格式。 wipefs -a -f /dev/nvme1n1 # 用零（空数据）覆盖盘的前 1GB 空间，彻底物理抹除可能残留的分区表（如 MBR/GPT）和元数据。 dd if=/dev/zero of=/dev/nvme1n1 bs=1M count=1024 status=progress # 刷新并更新 LVM 物理卷 (PV) 的元数据缓存，让系统感知到刚才对磁盘的擦除操作。 pvscan --cache # 刷新并更新 LVM 卷组 (VG) 的缓存，确保系统内核丢弃已经不存在的卷组信息。 vgscan --cache # 列出当前系统中所有激活与未激活的逻辑卷 (LV)，用于人工检查和确认旧的逻辑卷已被彻底释放。 lvscan # 强制两次 (-ff) 删除该盘上的 LVM 物理卷标签，即使元数据损坏也强制剥离其 LVM 属性。 pvremove -ff /dev/nvme1n1 # 强制删除本地 LVM 自动生成的旧 Ceph 卷组备份配置文件，静默忽略不存在的文件，防止旧配置干扰。 rm -f /etc/lvm/backup/ceph-* 2>/dev/null # 强制删除本地 LVM 的旧 Ceph 历史归档配置文件，清理干净 LVM 的历史痕迹。 rm -f /etc/lvm/archive/ceph-* 2>/dev/null # 摧毁 GPT 和 MBR 分区表结构，包括主分区表和备份分区表，将磁盘完全置为未初始化状态。 sgdisk --zap-all /dev/nvme1n1 # 对整块 NVMe SSD 执行强制 TRIM/Discard 操作，通知固态硬盘控制器释放所有闪存块，恢复出厂性能并彻底清空数据。 blkdiscard -f /dev/nvme1n1 # 通知 Linux 内核重新读取该盘的分区表，确保内核对该盘的认知立即与物理实际同步（变为完全空白盘）。 partprobe /dev/nvme1n1 # 最终检查命令。列出该盘的所有文件系统和挂载信息，此时应该输出完全空白的结果，证明清理成功。 lsblk -f /dev/nvme1n1 2上传&推送镜像。REGISTRY="deploy.bocloud.k8s:40443" # 1. 证书配置与服务重启 openssl s_client -connect $REGISTRY -showcerts /dev/null | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > harbor-guide.crt mv harbor-guide.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust systemctl daemon-reload && systemctl restart containerd # 2. 镜像定义数组 (格式: "tar包名|原Tag|新路径") IMAGES=( "ceph-csi-operator-v0.5.0.tar.gz|quay.io/cephcsi/ceph-csi-operator:v0.5.0|kubernetes/quay.io/cephcsi/ceph-csi-operator:v0.5.0" "rook-ceph-v1.19.2.tar.gz|docker.io/rook/ceph:v1.19.2|kubernetes/docker.io/rook/ceph:v1.19.2" "ceph-ceph-v19.2.3.tar.gz|quay.io/ceph/ceph:v19.2.3|kubernetes/quay.io/ceph/ceph:v19.2.3" "cephcsi-v3.16.1.tar.gz|quay.io/cephcsi/cephcsi:v3.16.1|kubernetes/quay.io/cephcsi/cephcsi:v3.16.1" "csi-provisioner-v6.0.0.tar.gz|registry.k8s.io/sig-storage/csi-provisioner:v6.0.0|kubernetes/registry.k8s.io/sig-storage/csi-provisioner:v6.0.0" "csi-resizer-v2.0.0.tar.gz|registry.k8s.io/sig-storage/csi-resizer:v2.0.0|kubernetes/registry.k8s.io/sig-storage/csi-resizer:v2.0.0" "csi-attacher-v4.10.0.tar.gz|registry.k8s.io/sig-storage/csi-attacher:v4.10.0|kubernetes/registry.k8s.io/sig-storage/csi-attacher:v4.10.0" "csi-snapshotter-v8.4.0.tar.gz|registry.k8s.io/sig-storage/csi-snapshotter:v8.4.0|kubernetes/registry.k8s.io/sig-storage/csi-snapshotter:v8.4.0" "csi-node-driver-registrar-v2.15.0.tar.gz|registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.15.0|kubernetes/registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.15.0" ) # 3. 批量导入、打标签、推送 for item in "${IMAGES[@]}"; do IFS="|" read -r tar_file orig_tag dest_path <<< "$item" ctr -n k8s.io image import "$tar_file" ctr -n k8s.io image tag "$orig_tag" "$REGISTRY/$dest_path" ctr -n k8s.io image push "$REGISTRY/$dest_path" done 集群内集群推送镜像到引导节点harbor仓库无需登录认证。 3接入Ceph。进入业务集群Master，将rook-ceph和rook-ceph-cluster的chart包上传至业务集群Master。# 进入chart包上传目录 tar -zxvf rook-ceph-v1.19.2.tgz tar -zxvf rook-ceph-cluster-v1.19.2.tgz 修改rook-ceph/values.yaml，全局搜索 "repository: "，在匹配的8个镜像地址前添加 "deploy.bocloud.k8s:40443/kubernetes/" ，指定去引导节点harbor仓库拉取镜像。修改rook-ceph/charts/ceph-csi-operator/values.yaml，同样搜索 "repository: "，在匹配的1个镜像地址前添加 "deploy.bocloud.k8s:40443/kubernetes/" 。修改rook-ceph-cluster/values.yaml： vimdiff截图1如下：修改后内容1，改动部分已添加行尾注释： 24 toolbox: 25 # -- Enable Ceph debugging pod deployment. See [toolbox](../Troubleshooting/ceph-toolbox.md) 26 enabled: true # 开启toolbox 27 # -- Toolbox image, defaults to the image used by the Ceph cluster 28 image: #quay.io/ceph/ceph:v19.2.3 29 # -- Toolbox tolerations 30 tolerations: [] 31 # -- Toolbox affinity 32 affinity: {} 86 # - name: my-registry-secret 87 88 # Specify these values to override the Ceph image in the cephClusterSpec below. 89 # If specifying these values, do not include the cephVersion section in the cephClusterSpec. 90 cephImage: 91 # The repository from which to pull the ceph image 92 repository: deploy.bocloud.k8s:40443/kubernetes/quay.io/ceph/ceph # 修改镜像拉取地址 93 # In production, use a specific version tag instead of the general v19 flag, which pulls the latest release and could result in different 94 # versions running within the cluster. See tags available at https://hub.docker.com/r/ceph/ceph/tags/. 95 # To be more precise, you can always use a timestamp tag such as quay.io/ceph/ceph:v19.2.3-20250717 96 tag: v19.2.3 97 # Whether to allow unsupported versions of Ceph. Currently Squid and Tentacle are supported. 98 # Future versions such as Tentacle (v20) would require this to be set to `true`. 138 # Default is false. 139 upgradeOSDRequiresHealthyPGs: false 140 141 mon: 142 # Set the number of mons to be started. Generally recommended to be 3. 143 # For highest availability, an odd number of mons should be specified. 144 count: 1 # 设置mon数量为1 145 # The mons should be on unique nodes. For production, at least 3 nodes are recommended for this reason. 146 # Mons should only be allowed on the same node for test environments where data loss is acceptable. 147 allowMultiplePerNode: true # 单节点设置true，允许单机运行同组件多个实例 148 149 mgr: 150 # When higher availability of the mgr is needed, increase the count to 2. 151 # In that case, one mgr will be active and one in standby. When Ceph updates which 152 # mgr is active, Rook will update the mgr services to match the active mgr. 153 count: 1 # 设置mgr数量为1 154 allowMultiplePerNode: true # 单节点设置true vimdiff截图2如下：修改后内容2，改动部分已添加行尾注释：251 placement: # 取消原文件中251-260行注释，限制核心组件运行在指定节点 252 all: 253 nodeAffinity: 254 requiredDuringSchedulingIgnoredDuringExecution: 255 nodeSelectorTerms: 256 - matchExpressions: 257 - key: kubernetes.io/hostname # 匹配节点hostname 258 operator: In 259 values: 260 - host31 # 指定host31 261 # podAffinity: 262 # podAntiAffinity: 263 # topologySpreadConstraints: 264 # tolerations: 265 # - key: storage-node 266 # operator: Exists 365 priorityClassNames: 366 mon: system-node-critical 367 osd: system-node-critical 368 mgr: system-cluster-critical 369 370 storage: # cluster level storage configuration and selection 371 useAllNodes: false # 不使用openFuyao集群所有节点 372 useAllDevices: false # 不使用探测到的所有磁盘 373 config: 374 osdsPerDevice: "1" # 每个磁盘启动一个osd pod 375 nodes: 376 - name: "host31" # 指定host31 377 devices: 378 - name: "nvme1n1" # host31上lsblk显示的裸盘NAME 379 - name: "nvme2n1" 380 - name: "nvme3n1" vimdiff截图3如下：修改后内容3，改动部分已添加行尾注释：477 cephBlockPools: 478 - name: ceph-blockpool 479 # see https://github.com/rook/rook/blob/master/Documentation/CRDs/Block-Storage/ceph-block-pool-crd.md#spec for available configuration 480 spec: 481 failureDomain: host 482 replicated: 483 size: 1 # 设置块存储副本数为1 484 # Enables collecting RBD per-image IO statistics by enabling dynamic OSD performance counters. Defaults to false. 485 # For reference: https://docs.ceph.com/docs/latest/mgr/prometheus/#rbd-io-statistics 486 # enableRBDStats: true 487 storageClass: 488 enabled: true 489 name: ceph-block 490 annotations: {} 544 cephFileSystems: 545 - name: ceph-filesystem 546 # see https://github.com/rook/rook/blob/master/Documentation/CRDs/Shared-Filesystem/ceph-filesystem-crd.md#filesystem-settings for available configuration 547 spec: 548 metadataPool: 549 replicated: 550 size: 1 # 设置文件存储元数据池副本数1 551 dataPools: 552 - failureDomain: host 553 replicated: 554 size: 1 # 设置文件存储数据池副本数1 555 # Optional and highly recommended, 'data0' by default, see https://github.com/rook/rook/blob/master/Documentation/CRDs/Shared-Filesystem/ceph-filesystem-crd.md#pools 556 name: data0 557 metadataServer: 558 activeCount: 1 559 activeStandby: true 560 resources: 622 - name: ceph-objectstore 623 # see https://github.com/rook/rook/blob/master/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md#object-store-settings for available configuration 624 spec: 625 metadataPool: 626 failureDomain: host 627 replicated: 628 size: 1 # 设置对象存储元数据池副本数1 629 dataPool: 630 failureDomain: host 631 # erasureCoded: # 注释掉631-633行，不使用纠删码 632 # dataChunks: 2 633 # codingChunks: 1 634 replicated: 635 size: 1 # 设置对象存储数据池副本数1 636 # parameters: # 注释636-637，不提前创建PG 637 # bulk: "true" 638 preservePoolsOnDelete: false # 取消安全保护，卸载ceph，底层的元数据池和数据池不残留在磁盘安装rook-ceph。# 进入chart包上传目录 kubectl create namespace rook-ceph helm install rook-ceph rook-ceph -n rook-ceph helm install rook-ceph-cluster rook-ceph-cluster -n rook-ceph 查看安装状态。# 确认 Operator 是否启动 kubectl get pod -n rook-ceph -l app=rook-ceph-operator # 用来观察 Operator 正在具体执行什么动作 kubectl logs -f -n rook-ceph -l app=rook-ceph-operator # 用来查看集群的总体声明阶段和核心报错信息: kubectl get cephcluster -n rook-ceph # 查看集群状态，osd up和in数量一致且大于0表明部署成功 kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph status 2.3 可靠性与容灾设计 2.3.1 openFuyao与Ceph扩容 2.3.1.1 openFuyao扩容在待扩容节点进行环境检查。# 将envcheck工具和配置环境传至同一目录 chmod +x envCheck ./envCheck check # 若识别到有docker，k8s，containerd等工具，手动卸载后重新check 浏览器访问集群引导节点管理页面，点击需要扩容的集群名称：点击新增节点，填写节点名称、ip和root密码：点击一键校验，通过校验后，点击确定openFuyao自动开始扩容。 2.3.1.2 Ceph扩容 rook-ceph默认配置为3节点部署，以扩容到三节点为例，给出扩容参考步骤。非三节点配置可能需要调整mon等组件的数量。 1配置时间同步。业务集群Master节点，修改/etc/chrony.conf。server 127.127.1.1 iburst # 可将127.127.1.1替换成路由器ip或者能连通外网和集群内机器的ip # Record the rate at which the system clock gains/losses time. driftfile /var/lib/chrony/drift # Allow the system clock to be stepped in the first three updates # if its offset is larger than 1 second. makestep 1.0 -1 rtcsync # Allow NTP client access from local network. allow 110.21.1.0/24 local stratum 10 ntsdumpdir /var/lib/chrony logdir /var/log/chrony 普通节点，修改/etc/chrony.conf。server {业务集群master_ip} iburst # Record the rate at which the system clock gains/losses time. driftfile /var/lib/chrony/drift # 无论何时，只要时差大于 1 秒，立刻强制跳跃对齐 makestep 1.0 -1 # Enable kernel synchronization of the real-time clock (RTC). rtcsync # Save NTS keys and cookies. ntsdumpdir /var/lib/chrony # Specify directory for log files. logdir /var/log/chrony 在所有节点执行： systemctl restart chronyd 2修改ceph-cluster配置。编辑 rook-ceph-cluster/values.yaml，原文件可解压chart包获得，对比原文件修改内容如下：# 启用toolbox 26 enabled: true 27 # -- Toolbox image, defaults to the image used by the Ceph cluster 28 image: deploy.bocloud.k8s:40443/kubernetes/quay.io/ceph/ceph:v19.2.3 29 # -- Toolbox tolerations # 修改ceph镜像拉取地址 90 cephImage: 91 # The repository from which to pull the ceph image 92 repository: deploy.bocloud.k8s:40443/kubernetes/quay.io/ceph/ceph # 集群节点和磁盘配置 370 storage: # cluster level storage configuration and selection 371 useAllNodes: false 372 useAllDevices: false 374 nodes: 375 - name: host31 # 节点hostname，以kubectl get node的NAME列为准 376 config: 377 osdsPerDevice: "1" # 每块磁盘启动一个osd 378 devices: 379 - name: "nvme3n1" # 托管给ceph的裸盘，以lsblk的NAME列为准，也可填写设备绝对路径 380 - name: "nvme2n1" 381 - name: "nvme1n1" 382 - name: host30 # 新增节点 383 config: 384 osdsPerDevice: "1" 385 devices: 386 - name: "nvme3n1" # 新增节点上托管给ceph的裸盘 387 - name: "nvme2n1" 388 - name: "nvme1n1" 389 - name: host29 390 config: 391 osdsPerDevice: "1" 392 devices: 393 - name: "sdb" 394 - name: "sdc" 395 - name: "sdd" 3清理磁盘。确保磁盘为裸盘，可以给Ceph使用。停止rook-ceph-operator，避免干扰：kubectl scale deployment -n rook-ceph rook-ceph-operator --replicas=0 登录扩容节点，清理磁盘，以nvme1n1为例：# 停止可能残留的服务 sudo systemctl stop ceph-osd.target sudo pkill -f ceph-osd # 删除数据目录 sudo rm -rf /var/lib/rook /var/lib/ceph /etc/ceph # 清除 LVM 元数据 sudo vgremove -f ceph 2>/dev/null sudo vgremove -f ceph-* 2>/dev/null sudo lvremove -f /dev/ceph/* 2>/dev/null sudo pvremove -f /dev/nvme1n1 # 用零（空数据）覆盖盘的前 1GB 空间，抹除可能残留的分区表（如 MBR/GPT）和元数据。 dd if=/dev/zero of=/dev/nvme1n1 bs=1M count=1024 status=progress # 擦除分区表 sudo sgdisk --zap-all /dev/nvme1n1 # 清除文件系统签名 sudo wipefs -a /dev/nvme1n1 sudo lsblk -f /dev/nvme1n1 # 应无输出唤醒operator： kubectl scale deployment -n rook-ceph rook-ceph-operator --replicas=1 4扩容Ceph。应用配置，进行扩容： # 应用配置 helm upgrade rook-ceph-cluster ./rook-ceph-cluster -n rook-ceph # 查看osd启动情况 kubectl logs -n rook-ceph -l app=rook-ceph-osd-prepare-host29 -f kubectl logs -n rook-ceph -l app=rook-ceph-osd-prepare-host30 -f # 查看所有 OSD Pod kubectl get pods -n rook-ceph | grep osd # 查看 OSD 树 kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- ceph osd tree # 查看集群健康状态 kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- ceph -s 2.3.2 配置定时pvc快照 1安装k8s官方快照CRD。# 下载并应用集群范围的快照 CRD wget https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v8.2.1/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml wget https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v8.2.1/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml wget https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v8.2.1/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml kubectl apply -f snapshot.storage.k8s.io_volumesnapshotclasses.yaml kubectl apply -f snapshot.storage.k8s.io_volumesnapshotcontents.yaml kubectl apply -f snapshot.storage.k8s.io_volumesnapshots.yaml 2安装通用快照控制器（Snapshot Controller）。# 部署快照控制器（通常部署在 kube-system 命名空间中） wget https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v8.2.1/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml wget https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v8.2.1/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml kubectl apply -f rbac-snapshot-controller.yaml kubectl apply -f setup-snapshot-controller.yaml 3重启确保 rook-ceph csi 容器正确识别。kubectl rollout restart deployment -n rook-ceph rook-ceph-operator kubectl rollout restart deployment ceph-csi-controller-manager -n rook-ceph 4创建 VolumeSnapshotClass。创建ceph-rbd-snapshotclass.yaml。apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: rook-ceph-rbd-snapshotclass driver: rook-ceph.rbd.csi.ceph.com # 核心：指向 Rook-Ceph 驱动 deletionPolicy: Delete parameters: clusterID: rook-ceph csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/snapshotter-secret-namespace: rook-ceph 创建VolumeSnapshotClass。 kubectl apply -f ceph-rbd-snapshotclass.yaml 给 VolumeSnapshotClass 加上一个特殊的标签（Annotation）。kubectl annotate volumesnapshotclass rook-ceph-rbd-snapshotclass snapshot.storage.k8s.io/is-default-class="true" 5部署MinIo。 Velero可以帮助我们实现指定namespace定时pvc备份，但Velero 需要通过MinIo来存放 K8s 的 YAML 元数据（比如 Pod、PVC 的定义配置）。创建命名空间。 kubectl create namespace velero-minio 获取MinIo镜像。# 安装了docker并且能访问引导节点的机器执行 docker pull minio/minio:RELEASE.2024-01-11T07-46-16Z docker tag minio/minio:RELEASE.2024-01-11T07-46-16Z deploy.bocloud.k8s:40443/kubernetes/minio/minio:RELEASE.2024-01-11T07-46-16Z docker push deploy.bocloud.k8s:40443/kubernetes/minio/minio:RELEASE.2024-01-11T07-46-16Z yaml配置。--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: minio-pvc namespace: velero-minio spec: storageClassName: ceph-block accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: minio namespace: velero-minio labels: app: minio spec: strategy: type: Recreate selector: matchLabels: app: minio template: metadata: labels: app: minio spec: nodeName: host31 containers: - name: minio image: deploy.bocloud.k8s:40443/kubernetes/minio/minio:RELEASE.2024-01-11T07-46-16Z args: - server - /data - --console-address - :9001 env: - name: MINIO_ROOT_USER value: "veleroadmin" - name: MINIO_ROOT_PASSWORD value: "veleropassword123" ports: - containerPort: 9000 name: minio-api - containerPort: 9001 name: minio-console volumeMounts: - mountPath: /data name: minio-storage volumes: - name: minio-storage persistentVolumeClaim: claimName: minio-pvc --- apiVersion: v1 kind: Service metadata: name: minio-service namespace: velero-minio spec: type: NodePort ports: - port: 9000 targetPort: 9000 name: minio-api - port: 9001 targetPort: 9001 nodePort: 31901 name: minio-console selector: app: minio 管理页面部署MinIO。登录http://<集群任意节点的IP>:31901。创建velero-k8s-backup bucket。 6安装 Velero。下载 Velero 命令行工具（Client）。wget https://github.com/velero-io/velero/releases/download/v1.17.2/velero-v1.17.2-linux-arm64.tar.gz tar -zxvf velero-v1.17.2-linux-arm64.tar.gz mv velero-v1.17.2-linux-arm64/velero /usr/local/bin/ 准备 Velero 认证文件。可以是空文件占位，安装需要，但Velero以文件方式识别登录凭证有问题。cat < ./credentials-velero aws_access_key_id=veleroadmin aws_secret_access_key=veleropassword123 EOF 依赖镜像准备。docker pull velero/velero:v1.17.2 docker pull velero/velero-plugin-for-aws:v1.13.2 docker tag velero/velero:v1.17.2 deploy.bocloud.k8s:40443/kubernetes/velero/velero:v1.17.2 docker tag velero/velero-plugin-for-aws:v1.13.2 deploy.bocloud.k8s:40443/kubernetes/velero/velero-plugin-for-aws:v1.13.2 docker push deploy.bocloud.k8s:40443/kubernetes/velero/velero:v1.17.2 docker push deploy.bocloud.k8s:40443/kubernetes/velero/velero-plugin-for-aws:v1.13.2 安装Velero服务端。velero install \ --provider aws \ --image deploy.bocloud.k8s:40443/kubernetes/velero/velero:v1.17.2 \ --plugins deploy.bocloud.k8s:40443/kubernetes/velero/velero-plugin-for-aws:v1.13.2 \ --bucket velero-k8s-backup \ --secret-file ./credentials-velero \ --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio-service.velero-minio.svc.cluster.local:9000 \ --features=EnableCSI \ --use-volume-snapshots=true 打入patch。解决凭证问题，关闭aws探测。kubectl patch deployment velero -n velero --type='json' -p='[ { "op": "add", "path": "/spec/template/spec/nodeSelector", "value": {"kubernetes.io/hostname": "host31"} }, { "op": "replace", "path": "/spec/template/spec/containers/0/env", "value": [ {"name": "AWS_ACCESS_KEY_ID", "value": "veleroadmin"}, {"name": "AWS_SECRET_ACCESS_KEY", "value": "veleropassword123"}, {"name": "AWS_EC2_METADATA_DISABLED", "value": "true"} ] } ]' 检查Velero状态。kubectl get pod -n velero velero backup-location get 7创建pvc快照。定时快照。velero schedule create fast-verify-snapshot --schedule="*/5 * * * *" --include-namespaces <命名空间> --snapshot-volumes=true --ttl 1h 手动触发快照。velero backup create test-snapshot-backup --include-namespaces <命名空间> --snapshot-volumes=true fast-verify-snapshot: 任务名称，作为后续管理该定时任务的唯一标识。 --schedule="*/5 * * * "：使用标准的 Cron 表达式。/5 * * * * 表示每分钟执行一次。 --include-namespaces: 指定备份范围。仅备份这些命名空间下的资源。 --snapshot-volumes=true: 核心参数。启用 CSI 快照功能。这意味着 Velero 不会仅仅把 PVC 的配置备份成 YAML，而是会调用 Rook-Ceph CSI 驱动，在存储后端（Ceph）执行真正的块存储快照。 --ttl 1h: 保留策略。快照在创建 1 小时后会被标记为过期，并由 Velero 清理进程自动从 MinIO（元数据）和 Ceph（物理快照）中删除。 8管理快照。操作领域命令功能描述备份管理 velero backup get 查看所有备份任务及其状态 velero backup describe 查看备份详细元数据（包含快照 ID 等） velero backup delete 删除备份任务（同时清理 MinIO 与底层快照） velero backup delete –all 清理所有备份记录（慎用）定时任务 velero schedule get 列出当前所有定时备份任务 velero schedule delete 删除定时任务，停止后续自动备份 K8s 快照层 kubectl get volumesnapshot -n 查看指定命名空间的快照资源状态 kubectl get volumesnapshotcontent 查看集群级快照内容对象 kubectl delete volumesnapshot -n 手动删除单个快照 CRD 对象 Ceph 底层 kubectl exec -it -n rook-ceph deploy/rook-ceph-tools – bash 进入 Ceph 调试工具箱 rbd -p ls 列出存储池中所有的 PVC 镜像 rbd -p snap ls 查看特定镜像的物理快照列表系统监测 velero backup-location get 验证 Velero 与 S3 (MinIO) 的连接状态 kubectl get pods -n velero 检查 Velero 控制器运行状态 2.3.3 极速容灾与数据重建 2.3.3.1 容灾场景场景编号故障类型具体触发动作数据是否丢失能否自动恢复恢复手段 F1 Pod 删除（Deployment） kubectl delete pod 或容器崩溃否能（Deployment 控制器自动重建 Pod，PVC 保留）无需人工干预 F2 Pod 删除（StatefulSet） kubectl delete pod 或节点驱逐否能（StatefulSet 控制器重建同名 Pod，自动绑定原 PVC）无需人工干预 F3 Deployment 删除 kubectl delete deployment 否（PVC 默认保留）不能（需手动重新创建 Deployment）重新创建 Deployment YAML，PVC 自动复用 F4 StatefulSet 删除 kubectl delete statefulset 否（PVC 保留）不能（需手动重新创建 StatefulSet）重新创建 StatefulSet，需确保 PVC 名称匹配（通常可保留原 PVC） F5 Helm 卸载（未配置删除 PVC） helm uninstall 否（PVC 保留）不能（需手动重新部署 Helm Chart）重新 helm install，Chart 会重新绑定到原有 PVC（如果 PVC 名称与 Chart 预期一致） F6 Helm 卸载（配置了删除 PVC） helm uninstall --delete-pvcs 或 Chart 中有 pre-delete 钩子删除 PVC 是不能从 VolumeSnapshot 恢复 PVC 后再部署 Chart F7 PVC 误删除 kubectl delete pvc 是（Delete 回收策略下底层 PV 和 Ceph 数据被清除）不能从 VolumeSnapshot 恢复（若提前创建了快照）；否则数据永久丢失 F8 PV/PVC 损坏（底层 Ceph RBD 映像损坏）磁盘坏道、OSD 数据损坏、PG 不一致可能（部分或全部数据不可读）部分能（Ceph 可从健康副本自动修复 PG；若三副本均损坏则不能）自动：ceph pg repair 或 ceph pg force-recovery；手动：从 VolumeSnapshot 恢复 F9 Ceph OSD 全部损坏（某节点永久故障）节点硬件损坏、磁盘损坏视副本分布而定（若该节点包含所有副本则丢数据）能（剩余健康 OSD 自动恢复数据，前提是有足够副本数）等待 Ceph 自愈，或替换硬件后恢复 F10 Ceph Pool 被误删除 ceph osd pool delete 是不能从 RBD 快照或 VolumeSnapshot 恢复（前提是快照不受影响） F11 etcd 元数据丢失（但 Ceph 底层数据完好） etcd 数据目录损坏、etcd 集群崩溃元数据丢失，但底层存储数据仍存在不能从 etcd 快照恢复元数据；恢复后 PVC 对象重现，自动关联底层 RBD 映像 F12 存储空间不足（预警）业务写入量突增，PVC 容量达到阈值否能在线修改 PVC 定义，触发底层 RBD 实时扩容，无需重启 Pod F13 节点宕机（Pod 被驱逐）节点断电、网络隔离否（PVC 是远程存储）能（Kubernetes 自动将 Pod 调度到其他节点，PVC 重新挂载）无需人工干预，但需确保节点在一定时间内恢复，否则 Ceph 会标记 OSD down 并触发数据重平衡 2.3.3.2 典型场景演示 2.3.3.2.1 场景F5 1创建资源。进入master节点终端任意目录。# 创建一个临时目录 mkdir f5-test-chart cd f5-test-chart # 创建 Chart 骨架 helm create f5-app 添加f5-app/templates/pvc.yaml文件，内容如下。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: {{ .Release.Name }}-pvc namespace: {{ .Release.Namespace }} spec: accessModes: - ReadWriteOnce storageClassName: ceph-block resources: requests: storage: 1Gi 修改f5-app/templates/deployment.yaml，内容如下。apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Release.Name }}-app namespace: {{ .Release.Namespace }} spec: replicas: 1 selector: matchLabels: app: {{ .Release.Name }} template: metadata: labels: app: {{ .Release.Name }} spec: nodeName: host31 containers: - name: writer image: deploy.bocloud.k8s:40443/kubernetes/busybox:1.36.1 command: ["/bin/sh"] args: ["-c", "while true; do echo $(date): test-data >> /data/f5.log; sleep 5; done"] volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: {{ .Release.Name }}-pvc 安装f5-app。# 安装 Chart，指定命名空间 helm install f5-test ./f5-app -n recovery-test 部署完成后等待一段时间，让pod写入数据。 2记录故障前状态。业务集群管理页面，工作负载-pod-命名空间，选择 recovery-test。点击对应pod名称进入pod后，点击终端唤起pod内终端。记录文件行数和开头内容。wc -l /data/f5.log head -n 10 /data/f5.log 3模拟故障。管理页面卸载f5-app。 4恢复检查。重新安装f5，进入终端f5-test-chart目录。helm install f5-test ./f5-app -n recovery-test 管理页面查看f5-app状态。均重新拉起进入pod终端，查看文件状态，文件行数增加，头部数据不变，pod已恢复并正常运行。 2.3.3.2.2 场景F7 1前置准备。确认已配置快照。# 查看定时快照配置 velero schedule get # 若recovery-test命名空间未配置定时快照，使用如下命令配置 velero schedule create recovery-test-snapshot --schedule="*/1 * * * *" --include-namespaces recovery-test --snapshot-volumes=true --ttl 1h # 模拟测试，快照任务每分钟执行1次，快照保留1小时 2创建资源。业务集群管理页面-右上角一键部署-前往部署。使用如下yaml配置创建pvc和pod。--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: f7-test-pvc namespace: recovery-test spec: accessModes: - ReadWriteOnce storageClassName: ceph-block resources: requests: storage: 1Gi --- kubectl apply -f - < > /data/f7.log; sleep 5; done"] volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: f7-test-pvc 3记录故障前状态。业务集群管理页面，工作负载-pod-命名空间，选择 recovery-test。点击对应pod名称进入pod后，点击终端唤起pod内终端。记录文件行数和开头内容。wc -l /data/f7.log head -n 10 /data/f7.log 4模拟故障。# 停止业务负载，解除 PVC 挂载占用 kubectl delete deployment f7-test-deploy -n recovery-test # 确认 PVC 不再被占用 kubectl describe pvc f7-test-pvc -n recovery-test # 删除pvc kubectl delete pvc f7-test-pvc -n recovery-test 5恢复检查。# 查看可用pvc快照 velero backup get # 选择最近的快照进行恢复 velero restore create --from-backup recovery-test-snapshot-20260613064531 --include-namespaces recovery-test # 跟踪恢复进度 velero restore get 进入pod终端，查看文件状态，文件行数增加，头部数据不变，pod已恢复并正常运行。 2.3.3.2.3 场景F8 1前置准备。确认已配置快照。# 查看定时快照配置 velero schedule get # 若recovery-test命名空间未配置定时快照，使用如下命令配置 velero schedule create recovery-test-snapshot --schedule="*/5 * * * *" --include-namespaces recovery-test --snapshot-volumes=true --ttl 1h # 模拟测试，快照任务每分钟执行5次，快照保留1小时 2创建资源。业务集群管理页面-右上角一键部署-前往部署。使用如下yaml配置创建pvc和pod。--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: f8-test-pvc namespace: recovery-test spec: accessModes: - ReadWriteOnce storageClassName: ceph-block resources: requests: storage: 1Gi --- apiVersion: v1 kind: Pod metadata: name: f8-test-pod namespace: recovery-test labels: app: f8-test spec: nodeName: host31 containers: - name: writer image: deploy.bocloud.k8s:40443/kubernetes/busybox:1.36.1 imagePullPolicy: IfNotPresent command: ["/bin/sh"] args: ["-c", "while true; do echo $(date): test-data-f8 >> /data/f8.log; sleep 5; done"] volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: f8-test-pvc 3记录故障前状态。业务集群管理页面，工作负载-pod-命名空间，选择 recovery-test。点击对应pod名称进入pod后，点击终端唤起pod内终端。记录文件行数和开头内容。wc -l /data/f8.log head -n 10 /data/f8.log 4模拟故障。# 获取 PVC对应PV 名称 PV_NAME=$(kubectl get pvc f8-test-pvc -n recovery-test -o jsonpath='{.spec.volumeName}') # 获取对应RBD 映像名 RBD_NAME=$(kubectl get pv $PV_NAME -o jsonpath='{.spec.csi.volumeHandle}') # 查看rbd对应设备 lsblk | grep -B5 $RBD_NAME # 破坏rbd dd if=/dev/zero of=/dev/rbd6 bs=4M count=10 conv=fsync # lsblk确认rbd序号确认数据被破坏。 5恢复检查。# 查看可用pvc快照 velero backup get # 清理损坏rbd对应的pvc和pod等资源 kubectl delete pod f8-test-pod -n recovery-test --force --grace-period=0 kubectl delete pvc f8-test-pvc -n recovery-test # 选择最近的快照进行恢复 velero restore create --from-backup recovery-test-snapshot-20260613075531 --include-namespaces recovery-test recovery-test-snapshot-20260613075531 # 跟踪恢复进度 velero restore get 进入pod终端，查看文件状态，文件行数增加，头部数据不变，pod已恢复并正常运行。 ----结束 2.3.3.2.4 场景F12 1前置准备。确认sc支持扩容。# 检查 StorageClass 是否支持扩容 kubectl get sc ceph-block -o yaml | grep allowVolumeExpansion # 预期输出：allowVolumeExpansion: true # 如果不支持，需要 patch StorageClass kubectl patch sc ceph-block -p '{"allowVolumeExpansion":true}' 2创建资源。--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: f12-test-pvc namespace: recovery-test spec: accessModes: - ReadWriteOnce storageClassName: ceph-block resources: requests: storage: 1Gi # 初始容量 1GB，用于演示扩容 --- apiVersion: v1 kind: Pod metadata: name: f12-test-pod namespace: recovery-test labels: app: f12-test spec: nodeName: host31 containers: - name: writer image: deploy.bocloud.k8s:40443/kubernetes/busybox:1.36.1 imagePullPolicy: IfNotPresent command: ["/bin/sh"] args: ["-c", "while true; do dd if=/dev/zero of=/data/test.dat bs=1M count=10 2>/dev/null; echo $(date): Wrote 10MB >> /data/f12.log; sleep 10; done"] volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: f12-test-pvc 3记录扩容前状态。进入pod内，查看/data大小。 4扩容。# 步骤1：确认 Pod 处于运行状态 kubectl get pod f12-test-pod -n recovery-test # 步骤2：执行在线扩容（从 1Gi 扩容到 2Gi） kubectl patch pvc f12-test-pvc -n recovery-test -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}' # 步骤3：等待几秒钟，查看 PVC 容量变化 kubectl get pvc f12-test-pvc -n recovery-test -w 5恢复检查。进入pod，查看/data容量。 ----结束 2.4 小集群算力底座进阶能力包括虚机/容器绑核、毕昇JDK替换openJDK8、etcd组件Go编译、KAE硬加速、弹性内存等特性的使用参考见第四章 2.4.1 虚机pod管理约束：当前版本支持命令行工具方式，后续版本增加web页管理平台。 1部署kubevirt。依赖镜像准备。基于kubevirt1.8.3验证，最新版本可通过curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | grep tag_name | cut -d '"' -f 4获取。KubeVirt 核心组件（operator/CRD 自动部署）： - quay.io/kubevirt/virt-operator:v1.8.3 - quay.io/kubevirt/virt-api:v1.8.3 - quay.io/kubevirt/virt-controller:v1.8.3 - quay.io/kubevirt/virt-handler:v1.8.3 - quay.io/kubevirt/virt-launcher:v1.8.3 存储组件（可选）： - quay.io/kubevirt/cdi-operator:v1.58.0 - quay.io/kubevirt/cdi-controller:v1.58.0 - quay.io/kubevirt/cdi-apiserver:v1.58.0 - quay.io/kubevirt/cdi-uploadproxy:v1.58.0 - quay.io/kubevirt/cdi-uploadserver:v1.58.0 - quay.io/kubevirt/cdi-importer:v1.58.0 - quay.io/kubevirt/cdi-cloner:v1.58.0 网络组件（可选）： - quay.io/kubevirt/bridge-marker - quay.io/kubevirt/kubemacpool - quay.io/k8snetworkplumbingwg/multus-cni VM 模板/演示镜像（可选）： - quay.io/kubevirt/cirros-container-disk-demo 部署kubevirt。# 安装 KubeVirt Operator export KUBEVIRT_VERSION=1.8.3 wget https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml kubectl create -f kubevirt-operator.yaml # 检查 operator 是否在运行 kubectl get pods -n kubevirt # 部署 KubeVirt wget https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-cr.yaml kubectl create -f kubevirt-cr.yaml # 检查 CRD 是否注册 kubectl get crd | grep kubevirt # 安装 virtctl 命令行工具 curl -Lo virtctl https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/virtctl-${KUBEVIRT_VERSION}-linux-arm64 chmod +x virtctl && mv virtctl /usr/local/bin/ 2管理虚机。创建虚机。示例yaml文件。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: testvm namespace: kubevirt # 指定命名空间 spec: running: true template: metadata: labels: # 用于关联 Domain kubevirt.io/domain: testvm spec: domain: cpu: cores: 2 resources: requests: memory: 2Gi devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: quay.io/kubevirt/cirros-container-disk-demo:v1.8.3 # 系统镜像 - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config password: password chpasswd: { expire: False } 管理虚机。操作分类描述命令示例创建/启动启动已定义的虚拟机 virtctl start 停止/关闭强制或优雅关闭虚拟机 virtctl stop 重启重启虚拟机实例 virtctl restart 控制台访问进入虚拟机图形/字符界面 virtctl console 远程桌面通过 VNC 访问图形界面 virtctl vnc 暂停/恢复暂停虚拟机运行（挂起） virtctl pause / unpause 状态查询查看虚拟机运行状态 kubectl get vm, kubectl get vmi 查看详情查看 VM 配置与事件 kubectl describe vm 清理删除删除虚拟机资源对象 kubectl delete vm 2.4.2 对接机密容器机密容器是云原生安全领域的高阶形态。它在传统 Kata 容器（轻量级虚拟机隔离）的基础上，深度融合了鲲鹏 TEE（可信执行环境）技术。其核心逻辑是将传统的轻量级虚拟机替换为基于 VirtCCA 架构的“机密虚拟机”，利用硬件级的内存加密与访问控制，彻底打破了“云平台管理员亦可读取租户内存数据”的安全边界。机密容器通过在 Kubernetes 标准管理栈（K8s + containerd）下集成硬件可信基，实现了计算过程的不可见、不可篡改与不可伪造，是保障敏感算法资产与核心隐私数据的终极解决方案。 openFuyao对接机密容器参考实践请参考：openFuyao对接机密容器-3.7机密容器部署章节。 3 一体机算力底座 3.1 整体架构在一体机场景下，传统的算力方案面临部署复杂、资源利用率低、算力调度不灵活等缺陷。一体机算力底座基于昇腾服务器、鲲鹏服务器等硬件平台，以openEuler操作系统和原生Docker方式为基础软件平台，提供简单容器管理和场景化的自动化部署方案。在资源管理方面，通过算力切分提升NPU资源利用率，通过容器NUMA亲和降低性能损耗，通过弹性内存和存储算法优化提升系统资源使用效率；在安全与密码计算加速方面，通过TEE内生国密增强数据保护能力，通过KAE硬件能显著提升整体计算效率。整体来看，该方案将操作系统、Docker 容器、基础使能套件与昇腾/鲲鹏硬件能力协同融合，为一体机场景提供简单易部署、资源可隔离、性能更稳定、安全能力更完善的算力底座。 3.2 部署形态为满足不同ISV伙伴的应用部署需求，本一体机方案提供物理机与容器两种灵活的部署形态。伙伴可根据应用特性、性能要求及运维习惯，选择最适宜的部署方式。物理机部署定义：物理机部署是指将ISV的软件或应用直接安装并运行在底层的物理服务器上，应用独占完整的操作系统和硬件资源（如CPU、内存、存储、网络）。涉及组件： ●硬件层：鲲鹏/昇腾服务器。 ●操作系统：基于openEuler操作系统，提供稳定、安全的运行环境。 ●基础库与驱动：包括KAE（硬件加速引擎）驱动、加速库（如KSL）、网卡驱动等，为上层应用提供硬件加速能力。 ●中间件与数据库：可直接在物理机上部署数据库（如openGauss）、消息队列等中间件。示例场景：对于核心数据库或高性能计算类应用，推荐采用物理机部署方式。例如，将企业的核心交易数据库直接部署在鲲鹏物理机上，可以充分利用物理机的独占资源，确保数据库获得最高的I/O吞吐量和稳定的CPU响应，避免资源争抢带来的性能波动。容器部署定义：容器部署是指将ISV的应用及其依赖环境打包成Docker镜像，以容器化方式运行在物理机操作系统之上。容器之间共享底层主机的内核，但彼此在进程、文件系统、网络等方面实现隔离。涉及组件： ●容器运行时：采用Docker等主流容器引擎，提供轻量化的应用运行环境。 ●基础镜像：提供预置了KAE加速库、性能调优组件等基础能力的OS镜像，便于伙伴快速构建应用容器。示例场景：对于AI推理或微服务架构的应用，推荐采用容器部署方式。例如，可以将AI教学实训平台中的在线推理服务容器化部署，利用容器的快速启动和弹性伸缩能力，灵活应对突发的教学访问高峰；同时，容器轻量化的特性也便于快速发布和迭代新的AI模型。 3.3 基础使能套件适用场景计算 ●NPU一卡多用场景：在高校人工智能实训课程场景下，主要以小模型场景应用为主，导致NPU算力利用率低、硬件成本高、多并发下出现资源争抢等问题。本方案通过昇腾NPU软切分+容器绑核与QoS隔离的特性组合。通过NPU软切分技术实现单NPU卡在多容器中的挂载使用，满足了整班教学的需求。优化了教育场景下的算力成本与算力资源使用效率。容器绑核对CPU、内存带宽和缓存等共享资源进行规划和限制，减少不同业务之间的资源争抢。保障了关键业务性能稳定。存储 ●对象存储场景：随着AI业务快速发展，训练和推理过程需要存储大量数据，MinIO凭借低成本、分布式、兼容S3协议和轻量化部署等特点，广泛应用于日志处理、源文件存储和知识库存储等场景。同时，AI集群要求高吞吐和低延迟，也对MinIO数据读取效率提出新的挑战。基础使能套件通过KAE硬件加速能力，将压缩/解压缩运算从CPU卸载至鲲鹏处理器的KAE引擎执行，在Client端对文件压缩后再传输和存储，从而降低CPU开销，优化网络带宽和磁盘空间占用。网络 ●网络数据包处理场景：网关业务场景，大流量网络报文接收面临传统内核协议栈开销大、数据包吞吐受限、转发延迟不稳定等挑战，从而影响网关报文处理和转发。基础使能套件提供DPDK网络优化方案进行应对。 DPDK网络优化：DPDK用于用户态数据面处理机制绕过linux内核协议栈，消除中断处理与上下文切换开销，充分释放鲲鹏处理器的算力，保障网络处理的高吞吐与低时延。安全 ●数据加密场景：数据加密场景中，一体机面临双重挑战：一方面，金融、政务等行业对敏感数据的机密性、完整性及国密合规有严格要求；另一方面，传统依赖外置密码卡/密码机的方案成本高昂、集成复杂，且纯软件加解密会大量消耗CPU资源，制约业务性能。基础使能套件提供TEE内生国密特性与KAE硬件加速加密特性的组合，构建软硬协同的安全加速能力，在保障数据安全与合规性的同时，降低 CPU 开销，提升加解密处理性能。 TEE内生国密特性：该特性基于鲲鹏处理器ARM TrustZone技术，在硬件层面划分出安全执行环境（TEE）与普通执行环境（REE），通过软硬件结合的方式构建内置于服务器的密码模块套件。该套件将SM2/SM3/SM4等国密算法集成于TEE OS可信执行环境内，密钥的生成、存储与运算全流程在硬件隔离区完成，无需外置密码卡即可满足国密二级标准要求，解决了传统方案成本高、集成复杂、扩展性差等痛点。 KAE硬件加速加密特性：该特性面向高并发、重负载的加解密场景，将计算密集型的加解密运算（如SM4、RSA等）从CPU卸载至鲲鹏处理器的KAE专用硬件加速引擎执行。该特性支持毕昇JDK中的KAE Provider，实现标准的Java 接口，对上层应用透明，基于Java语言开发的应用直接调用KAE加解密的硬加速能力，大幅降低CPU占用率与处理延迟。 4 基础使能套件特性集合 4.1 硬件资源利用率优化场景 4.1.1 NPU硬切分特性 ●概述特性说明：算力硬切分是昇腾HDK提供的能力。通过硬切分，我们可以把单张物理NPU卡切分为多张vNPU，再将其挂载到业务容器中使用。大幅提高了单卡吞吐性能以及NPU的算力利用率。背景：多业务和多租户场景下需要硬件隔离来提高效率并减少资源浪费。为了满足不同业务需求采用了容器化的方案，并根据不同的业务需求分配相应的计算资源如AICore、HBM等。方案：通过npu-smi工具调用昇腾HDK提供的硬切分模板对算力资源进行切分。 ●方案介绍算力硬切分可将NPU切分为多个vNPU实例，每个实例单独使用。提高算力利用率并提供硬件级隔离，避免业务之间因资源抢占出现中断。技术规格： 1、切分粒度：Atlas A2 推理系列产品：1切2，1切4；Atlas A3 推理系列产品：1/4，1/8 2、资源隔离：支持分成多个vGroup组，每个vGroup分配并独占AICORE数量、HBM内存、HBM带宽、AICPU个数。 3、资源监测：支持统计vNPU的AICORE利用率及显存占用量。 4、Qos保障：每个vNPU资源隔离，保障稳定的Qos。约束条件： 1、同个模型部署时不支持物理NPU+vNPU混合使用。 2、物理NPU虚拟化出vNPU后，不支持再将该物理NPU挂载到容器使用。 3、虚拟化实例模板是用于对整台服务器上所有NPU进行资源切分，不支持不同规格的标卡混插。如Atlas 300I Duo 支持48G和96G内存规格，不支持这两种内存规格的卡混插进行虚拟化。 4、一个推理服务只能绑定一张vNPU。 ●参考实践链接参考实践发布社区内容简介链接 NPU卡虚拟化硬切分参考实践昇腾社区主要用于介绍基于昇腾硬件驱动提供的硬切分能力，详细描述典型场景下虚拟化硬切分的方案。同时提供详细的操作指导，帮助用户快速将虚拟化硬切分应用到业务应用中。 NPU卡虚拟化硬切分参考实践 4.1.2 NPU软切分特性 ●概述特性说明：NPU软切分是一种面向多用户、多任务共享 NPU 的资源切分能力。该特性通过时间片轮转方式对算力、显存进行配额管理，实现单张物理NPU同时承载多个容器任务，提升NPU资源利用率。背景：在AI教学实训、模型开发验证等场景中，单个任务对算力性能要求相对较低，但需要同时支持多个用户运行训练或推理任务。如果每个用户独占一张 NPU，会造成硬件成本高、资源利用率低。因此，需要将单张 NPU 按一定比例切分给多个任务共享使用。方案：该方案基于vCANN-RT实现软切分能力，通过配置每个容器的AI Core配额、显存配额和调度策略，使多个容器能够共享同一张物理NPU。AI Core资源按时间片进行轮转调度，显存资源按配额进行限制，从而实现算力和显存的细粒度分配。 ●方案介绍方案简介：本方案支持 Kubernetes 和纯 Docker 两种部署方式。在Kubernetes场景下，通过Mindcluster组件完成NPU资源调度；在Docker场景下，需要用户手动挂载软切分动态库、配置文件、共享内存设备和物理NPU设备，并通过npu_info.config配置文件指定容器使用的NPU资源配额。技术规格： 1、本方案支持 Atlas 300I A2、Atlas 800I A2，适用于训练和推理场景。 2、AI Core算力资源支持按百分比配置，切分粒度不低于1%； 3、显存支持按容量配置，最小切分粒度为1MB。 4、单个物理NPU最多支持63个容器共享使用。使用约束： 1、每个容器分配的资源总和不能超过单卡资源。 2、一个容器最多只能使用一个物理NPU。 3、NPU需开启共享模式。 4、仅支持普通容器，不支持特权容器。 5、由于vCANN-RT解决方案使用了共享内存，需确保是可信且被授权的用户使用。 6、单个物理NPU卡支持的最大容器数量为63个。 7、若用户自己编译软切分动态库，则需要保证宿主机上CANN的版本和镜像中的CANN版本保持一致。 ●参考实践参考实践发布社区内容简介链接 NPU卡虚拟化软切分参考实践昇腾社区采用vCANN-RT算力软切分方案。通过预加载软切分动态库，拦截部分runtime API的调用，根据算力和显存资源配额信息，进行算力控制或显存控制。搭配MindCluster组件使用，可灵活分配整机算力资源。 NPU卡虚拟化软切分参考实践 4.1.3 弹性内存特性 ●概述特性说明：该特性旨在解决虚拟化场景中因内存冷热数据分布不均导致的资源浪费问题。通过智能识别并管理冷数据，将其迁移至低成本存储介质，实现在有限物理内存下部署更多虚拟机，显著降低内存配置需求与总体拥有成本。背景：企业数字化转型和虚拟化应用普及导致数据量激增，内存资源管理面临挑战。核心问题在于冷热数据混合存放：频繁访问的热数据需快速响应，而长期闲置的冷数据却占用大量昂贵内存。传统管理方式缺乏智能分层机制，无法自动识别并迁移冷数据至低成本存储。方案：通过用户态监测与内核态回收的协同机制，结合memlink模块进行内存冷热数据识别、内存热度分级，同时利用ZRAM模块使用内存作为交换区进行压缩存储，KAE提供硬件加速，达到动态回收冷页内存、提升物理内存利用率的效果，解决了虚拟化场景中冷数据长期占用内存、大页内存无法直接swap导致的资源浪费问题。 ●方案介绍本方案通过冷热页识别、动态回收与压缩存储技术，实现虚拟化场景下内存资源的弹性管理，支持内存超分以提升部署密度，同时依赖特定硬件（鲲鹏 CPU）与软件配置（2MB 大页）实现优化效果。技术规格： 1. 本方案适用于虚拟机场景，过内存超分提升虚拟机部署密度。 2. 本方案适用于虚拟机运行redis,nginx等应用，多虚拟机场景下性能损耗<15%。 3. 本方案突破传统大页内存无法直接 Swap 的限制，通过内核态 etmem 接口实现冷页回收。使用约束： 1. 当前仅支持虚拟化场景，物理机场景需后续版本支持。 2. 须使用 2MB 大页内存，且需在虚拟机 XML 配置中启用大页支持及动态分配标签。 3. 单虚拟机冷数据较少时，内存回收可能对性能有较大影响。 ●参考实践参考实践发布社区内容简介链接鲲鹏降内存配置高性价比参考实践鲲鹏社区本文介绍了通过冷热页识别、动态回收与压缩存储技术，实现虚拟化场景下内存资源的弹性管理，支持内存超分以提升部署密度的方案。鲲鹏降内存配置高性价比参考实践 4.2 KAE加速使能场景 4.2.1 KAE加速Java加解密性能特性 ●概述特性说明：Java加解密KAE加速是一种面向高并发、重负载加解密场景的硬件加速卸载能力。该特性通过将计算密集型的加解密运算（如SM4、RSA等）从CPU卸载至鲲鹏处理器的专用硬件加速引擎（KAE）执行，实现CPU占用率大幅降低、处理延迟显著减少，同时通过标准的Java Provider接口对上层应用透明，提升整体系统的安全处理效率与吞吐能力。背景：在金融等关键行业中，大量敏感数据（如客户信息、交易文件）在机构内外网间高频传输，须按法规要求采用国密算法（如SM4）加密。然而，传统Java应用依赖CPU执行软件加解密，导致CPU占用率过高、处理延迟增大，严重制约了业务办理效率和数据传输速度。方案：该方案基于毕昇JDK中的KAE Provider实现KAE硬加速能力，通过将加解密运算从CPU卸载至鲲鹏处理器的KAE硬件加速引擎执行，使Java应用能够利用硬件加速进行高效的加解密处理。加解密任务通过硬件引擎并行处理，CPU仅负责任务调度与数据传输，从而实现算力卸载与性能大幅提升。 ●方案介绍 Java KAE加解密可将计算密集型的加解密运算（如SM4、RSA、MD5等）从CPU卸载至专用硬件加速引擎执行，有效降低CPU占用率、减少处理延迟，并通过标准JCA/JCE接口对上层应用透明，无需修改业务代码即可获得硬件加速能力。技术规格： 1、加速粒度：支持对称加密（SM4）、非对称加密（RSA）、摘要算法（MD5）等主流加解密算法的硬件加速。 2、资源卸载：加解密运算由KAE硬件引擎承担，CPU仅负责I/O调度与上下文管理，显著释放CPU算力。约束条件： 1、仅支持在鲲鹏920系列及新型号服务器上使用，且需安装对应的KAE驱动和License（新型号可免License）。 2、需使用毕昇JDK（bishengJDK）并正确配置KAE Provider，OpenJDK等其他JDK版本不支持。 3、KAE硬加速仅针对特定算法生效（如SM4、RSA、MD5），非所有加解密算法均能加速。 ●参考实践参考实践发布社区内容简介链接 KAE加速JAVA加解密鲲鹏社区如何使用KAE加速java加解密算法鲲鹏KAE硬加速参考实践：实现Java加解密算法性能飞跃 4.2.2 KAE加速MinIO性能特性 ●概述特性说明：KAE加速MinIO是一种高性能压缩卸载能力。该特性通过将数据压缩/解压缩运算从CPU卸载至鲲鹏处理器的KAE硬件加速引擎执行，在Client端对文件进行压缩后传输与存储，从而优化网络带宽和磁盘空间占用，提升整体存储服务性能。背景：MinIO作为一款高性能开源对象存储系统，凭借其对Amazon S3协议的全面兼容、分布式架构设计及轻量化部署特性，已成为云原生时代主流的存储解决方案，广泛支撑日志处理、AI数据湖等场景。为充分释放鲲鹏服务器的硬件潜能并进一步提升MinIO应用性能，需要针对性地进行调优，其中对文本类日志文件进行压缩后再传输，是优化网络带宽和存储空间占用的有效手段。方案：推荐在鲲鹏服务器上对MinIO进行性能优化，主要包括： 1.系统性能调优：通过配置服务器高性能模式、应用绑核等方法，提升MinIO在鲲鹏服务器上的运行性能。 2.压缩传输方案：将原始文件使用KAE进行高性能压缩后再传输，以优化网络带宽和磁盘空间占用。该方案对文本日志类文件压缩效果较好，但对已压缩过的文件（如图片、视频）无效。 ●方案介绍该方案通过在MinIO Client端集成KAE压缩能力，实现性能优化。具体实现方式为： ●写入优化：Client端将原文件使用KAE压缩后再写入MinIO Server，MinIO Server存储压缩文件，同时减少存储空间和网络传输带宽占用。 ●读取优化：从MinIO Server读取文件时，返回压缩文件，Client端接收到后使用KAE解压再返回给应用，同样减少网络带宽占用。技术规格： 3.加速粒度：支持zlib格式的数据压缩与解压加速。 4.资源卸载：压缩/解压缩运算由KAE硬件引擎承担，CPU仅负责I/O调度与上下文管理，显著释放CPU算力。 5.透明集成：通过对MinIO Python SDK的API进行封装，在原有接口（如put_object/get_object）中增加参数（compress_mode/uncompress_mode）来使能KAE压缩/解压功能，上层应用改动小。约束条件： 6.仅支持在鲲鹏920系列及新型号服务器上使用，且需安装对应的KAE驱动和License（新型号可免License）。 7.压缩加速方案在Client端部署，Server端仅进行存储，无需特殊配置。 8.KAE硬加速仅对特定压缩格式（如zlib）生效，非所有压缩算法均能加速。 9.加速效果与文件压缩率正相关，压缩率越高（如文本文件），性能提升越明显；对已压缩文件（如图片、视频）无效果。 10.需正确配置KAE环境变量（如LD_LIBRARY_PATH），否则将回退至CPU软件压缩。 ●参考实践参考实践发布社区内容简介链接 KAE加速MinIO分布式存储鲲鹏社区利用KAE压缩特性加速MinIo数据传输基于鲲鹏KAE的MinIO压缩加速参考实践 4.3 NUMA亲和加速场景 4.3.1 DPDK网络优化 ●概述特性说明：该特性面向DPDK网络加速场景，通过KAOT工具对CPU、内存及中断等关键资源进行自动化调优，实现对DPDK数据包处理任务的性能保障，减少因系统通用配置导致的处理延迟与开销。背景：在网关等DPDK密集部署场景中，数据平面依赖对网络数据包的高效、低延迟处理。然而，传统网络路径需经由内核，频繁的中断和上下文切换会造成较大CPU开销。同时，服务器出厂通用配置无法充分发挥DPDK旁路内核、在用户态处理数据包的优势，导致CPU资源未能被最高效地利用。方案：通过KAOT自动化调优工具，针对DPDK场景专项使能CPU核心隔离、中断绑核、大页内存、禁用透明大页等调优项。将DPDK数据包处理任务绑定到指定CPU核心，并优化中断与内存配置，减少调度干扰和内存访问延迟，从而充分释放DPDK的性能潜力，保障网络处理的高吞吐与低时延。 ●方案介绍该方案通过在鲲鹏服务器上部署并使用KAOT（Kunpeng Auto Optimization Tool）自动化调优工具，针对特定业务场景（如DPDK网络加速、数据库等）自动完成系统级性能调优，解决因人工调优门槛高、效率低而导致的性能未能充分发挥的问题，实现系统性能的最佳配置。技术规格： 11.支持场景： ●DPDK网络加速场景：通过CPU隔离、中断绑核等调优，释放网络处理性能。 ●数据库场景：支持对openGauss和金仓（Kingbase）数据库进行专项参数调优。 ●边界网关一体机场景：集成核心隔离、大页内存、加速库安装等综合调优。 ●通用场景：提供基础的OS级性能优化。 12.核心功能： ●自动化调优：根据用户选择的调优项或应用场景，自动生成并执行调优配置文件。 ●基线管理：支持生成系统调优前的基线配置，便于对比和快速回退。 ●加速库集成：可自动化安装或卸载鲲鹏BoostKit加速库（如KSL库、毕昇JDK）。 ●灵活执行：支持全量或指定部分调优项执行，满足精细化管理需求。约束条件： 1. 需在鲲鹏920系列及新型号服务器上使用。 2. 需Python 3.9及以上版本。 3. 执行调优操作通常需要root或管理员权限。 4. 部分涉及BIOS修改的特性（如超线程配置）需在物理机上手动修改后方可生效。 ●参考实践附工具使用链接参考实践发布社区内容简介链接通算一体机性能综合调优参考实践鲲鹏社区本文针对鲲鹏服务器在特定业务场景下需手动进行复杂系统调优的痛点，提出了一套基于KAOT（Kunpeng Auto Optimization Tool）自动化调优工具的解决方案。该方案通过用户指定的调优项或应用场景(如DPDK网络加速场景)，自动完成调优配置文件生成、配置执行及鲲鹏BoostKit加速库安装等关键步骤，有效降低调优门槛，提升效率，实现系统性能的快速优化。通算一体机性能综合调优参考实践 4.3.2 容器绑核 ●概述特性说明：该特性面向虚拟化和容器混部场景，通过容器CPU绑核、虚拟机内存带宽QoS和L3 Cache控制，实现对关键业务的资源隔离与性能保障，减少CPU、内存带宽和缓存资源争抢。背景：在多虚机、多容器混合部署场景中，不同业务会共享底层硬件资源。高并发或业务高峰时，容易出现CPU调度干扰、内存带宽争抢和缓存竞争，导致关键业务时延升高、吞吐下降或性能波动。方案：在容器场景下通过在Docker、docker-compose、k8s配置文件中配置绑核参数实现CPU绑核；在虚拟机场景下基于鲲鹏处理器的MPAM能力，通过虚拟机XML配置内存带宽和L3 Cache资源，实现共享资源隔离，保障关键业务性能稳定。 ●方案介绍通过容器CPU绑核、虚拟机内存带宽QoS控制和L3 Cache资源控制，对CPU、内存带宽和缓存等共享资源进行规划和限制，减少不同业务之间的资源争抢，实现对关键业务的性能保障和对整体系统资源的可控使用。技术规格： ●本方案支持物理机多虚拟机部署、虚拟机内多容器部署等场景。 1）容器场景下，支持通过Docker、docker-compose、k8s配置文件中配置绑核参数实现CPU绑核，将关键业务容器固定运行在指定CPU核心上，保证关键业务容器的性能和稳定性。 2）虚拟机场景下，支持基于鲲鹏处理器的MPAM能力，对虚拟机的内存带宽和L3 Cache资源进行配置和控制，实现虚拟机之间共享硬件资源的隔离，避免单一业务过度占用内存带宽或缓存资源。 ●要在鲲鹏920新一代服务器上使用MPAM特性，需要使用配套OS和相关软件，如下表： .1软硬件配置表类别配置 CPU 鲲鹏920新型号（ 7270Z、5253Z、5252Z、5235Z、5230Z等）操作系统参考实践以openEuler 24.03 SP2为例（要求不低于该版本）虚拟化管理工具参考实践以libvirt 9.10.0为例（要求不低于该版本）虚拟化组件参考实践以QEMU 8.2.0为例（要求不低于该版本）约束条件： 1、必须明确指定虚拟机可使用的CPU核的范围，可根据NUMA拓扑和业务需求进行规划。 2、核心业务所绑定的CPU核心不得分配给其他虚拟机使用，以保证性能和资源隔离。 ●参考实践参考实践发布社区内容简介链接基于容器CPU绑核与虚机QoS控制的参考实践，保障关键业务性能和稳定性鲲鹏社区本文针对多虚机、多容器混合部署环境中常见的性能干扰与资源争抢问题，提出了一套基于CPU 绑核、内存带宽及L3 Cache控制的性能优化方案。通过对 CPU、内存带宽和缓存资源进行隔离与精细化控制，减少资源竞争带来的性能波动。基于容器CPU绑核与虚机QoS控制的参考实践，保障关键业务性能和稳定性 4.4 GO编译优化场景 ■概述特性说明：GO4oE（Go for openEuler）是面向鲲鹏处理器架构深度定制的高性能Go语言编译器。Go编译优化通过引入一系列针对鲲鹏芯片微架构的编译优化技术（包括原子操作优化、标准库Map优化、增强内联、反馈编译优化等），在无需修改业务源代码的前提下，显著提升Go语言应用程序在鲲鹏服务器上的运行性能，降低资源占用。背景：etcd作为Kubernetes的核心存储组件及独立的分布式键值数据库，其性能直接影响整个集群的交易处理能力。在某教育行业调优项目中，etcd资源占用率高且负载压力大，成为集群的主要性能瓶颈。同时，InfluxDB作为新能源集控系统中关键的时序数据库，承担着传感数据的实时采集与监测任务，对高并发写入和查询性能有极高要求。因此，需要针对鲲鹏920新型号服务器（支持超线程等新特性）对上述Go语言编写的数据库组件进行深度优化，以释放硬件潜能、提升整体业务性能。方案：以鲲鹏920新型号服务器为计算底座，通过全栈调优手段提升Go语言数据库组件的性能。调优手段涵盖系统侧优化（如NUMA绑核、GOGC调优）、编译侧优化（使用GO4oE编译器并开启鲲鹏专属优化选项、PGO反馈编译优化）以及BIOS侧优化（如开启超线程、CPU高性能模式、CPU预取、内存刷新策略）。同时，针对容器化部署场景（如K8s环境），提供了将优化后的二进制文件平滑替换至生产集群的实践指导。 ■方案介绍通过软硬件协同优化，全方位提升Go语言应用在鲲鹏平台上的性能。 ●系统优化：通过NUMA绑核与亲和性配置，将进程与内存约束在同一NUMA节点，减少跨NUMA访存开销；通过调整GOGC参数，在GC占用CPU资源与堆内存占用之间取得平衡。 ●编译优化：使用GO4oE编译器，并通过环境变量（如GOARM64、GOEXPERIMENT、GCFLAGS、LDFLAGS）开启一系列鲲鹏专属优化项，包括原子操作优化（kpatomic）、标准库Map优化、内存预取（prefetchmalloc）、函数对齐优化等。此外，还可采用PGO（Profile-Guided Optimization）反馈编译优化，基于业务负载采集的CPU profile数据进行二次编译，针对热点函数进行进一步优化。 ●BIOS优化：针对鲲鹏920新型号服务器，开启SMT超线程（每个物理核虚拟为两个逻辑核）以提升并发性能；设置CPU为高性能模式、使能硬件预取、配置内存刷新策略为Auto等，最大化硬件算力输出。 ●落地实践：在独立数据库或Kubernetes容器化部署场景下，提供将优化后的二进制文件重构为容器镜像，并通过修改StatefulSet或Deployment的YAML配置平滑升级至生产集群的方法，实现优化成果的业务落地。 ■参考实践参考实践发布社区内容简介链接基于鲲鹏Go编译优化的KV存储系统etcd性能调优参考实践鲲鹏社区介绍如何使用GO4oE编译器并开启特定编译选项对etcd进行重新编译优化。基于鲲鹏Go编译优化的KV存储系统etcd性能调优参考实践基于鲲鹏服务器的influxDB调优参考实践鲲鹏社区介绍在鲲鹏920新型号服务器上，通过系统优化、GO4oE编译优化及BIOS配置等全栈调优手段，提升InfluxDB时序数据库性能。基于鲲鹏服务器的influxDB调优参考实践 4.5 安全加解密场景 ■TEE内生国密特性 ●概述特性说明：该特性是基于华为自研可信执行环境操作系统（TEEOS）提供的密码模块套件特性，通过软硬件结合的方式实现国密算法能力，无需外置密码卡/密码机即可满足合规加密需求，符合国密二级标准，具备高可靠、低成本、高易用的特点。背景：数字化转型背景下，数据加密需求普遍存在于金融、监管等行业，需同时满足机密性、完整性及国密合规要求，但传统方案依赖外置密码卡/密码机，存在成本高、集成复杂、扩展性差、运维繁琐等痛点。方案：该方案通过软硬件结合的方式实现，具体分为三个层面： 13.硬件隔离：基于ARM TrustZone技术，在鲲鹏处理器上划分出安全的执行环境（TEE）和普通执行环境（REE），实现物理级别的安全隔离。 14.软件模块： ●TA部分：核心密码算法服务（如密钥生成、密码运算）运行在TEE OS的安全侧，确保运算过程和数据受到强力保护。 ●CA部分：在REE侧提供标准的国密接口库（libsdf.so），应用程序可像调用传统密码卡一样调用该接口，请求被自动转发至TEE侧处理。 15.密钥管理：方案内置安全存储服务单元，用于加密保存密钥等敏感数据。 ●方案介绍方案利用华为自研的TEE OS（可信执行环境操作系统）构建一个内生、免硬件的软件密码模块。该模块直接内置于鲲鹏服务器中，旨在为国密应用提供一种高性价比、易部署且合规的密码服务。技术规格：本方案支持银行与三方机构数据交互，金融安全网关等场景。 1、银行与三方机构数据交互场景下，在物理机上直接部署TEE套件，使用SM4算法进行加解密开发，适用于对性能要求较高的安全业务场景。 2、金融安全网关场景下，在虚拟机中部署TEE套件，使用SM2算法进行加解密开发，通过tee-gp-proxy实现虚拟机与物理机TEE之间的代理通信，适用于金融安全网关等多虚机隔离场景。本方案支持以下功能： - 密码算法：支持SM2（签名/加密）、SM4（ECB/CBC模式加解密）等国密算法。 - 密钥管理：支持密钥创建、删除、密码修改、导出导入、恢复出厂设置等操作，提供密钥管理工具（tee_key_manage）。 - SDF标准接口：提供符合GM/T 0018标准的SDF接口，包括设备/会话管理、单包与多包加解密、签名验证等。 - 虚拟机TEE代理：通过vtz_proxy和vtzfdriver实现虚拟机对物理机TEE的访问，支持多虚机并发使用TEE能力。约束条件： 1、当前本方案仅支持鲲鹏920新型号服务器，并且需要获取TEE商用license。 2、物理机需通过IBMC进行固件升级，升级CCOS,BIOS等固件以满足该特性版本需要。 3、虚拟机场景需编译打补丁的qemu（v6.2.0），在虚拟机配置中添加虚拟串口映射；若使用超融合平台需超融合厂商适配。 ●参考实践参考实践发布社区内容简介链接免加密卡，鲲鹏TEE内生国密高性价比参考实践鲲鹏社区本文介针对金融、监管等行业对于机密性、完整性及国密合规要求的加解密需求，提出了一套基于华为自研可信执行环境操作系统（TEE OS）提供的密码模块套件，通过软硬件结合的方式实现国密算法能力，无需外置密码卡/密码机的高可靠、低成本、高易用解决方案。免加密卡，鲲鹏TEE内生国密高性价比参考实践