华为云用户手册

使用场景 快照功能可以帮助您实现以下需求： 日常备份数据 通过对云硬盘定期创建快照，实现数据的日常备份，可以应对由于误操作、病毒以及黑客攻击等导致数据丢失或不一致的情况。 快速恢复数据 更换操作系统、应用软件升级或业务数据迁移等重大操作前，您可以创建一份或多份快照，一旦升级或迁移过程中出现问题，可以通过快照及时将业务恢复到快照创建点的数据状态。 例如，当由于云服务器 A的系统盘 A发生故障而无法正常开机时，由于系统盘 A已经故障，因此也无法将快照数据回滚至系统盘A。此时您可以使用系统盘 A已有的快照新创建一块云硬盘 B并挂载至正常运行的云服务器 B上，从而云服务器 B能够通过云硬盘 B读取原系统盘 A的数据。 当前CCE提供的快照能力与K8s社区 CS I快照功能一致：只支持基于快照创建新云硬盘，不支持将快照回滚到源云硬盘。 快速部署多个业务 通过同一个快照可以快速创建出多个具有相同数据的云硬盘，从而可以同时为多种业务提供数据资源。例如数据挖掘、报表查询和开发测试等业务。这种方式既保护了原始数据，又能通过快照创建的新云硬盘快速部署其他业务，满足企业对业务数据的多元化需求。

扩展网段规划说明 在添加扩展网段前，需做好网段规划，避免造成网段冲突。注意以下几点： 集群所在VPC下所有子网（包括扩展网段子网）不能和容器网段、服务网段冲突。 扩展网段选择10.0.0.0/8、172.16.0.0/12、192.168.0.0/16可能与集群Master分配的IP冲突，尽量避免选择这三个网段作为扩展网段。 同VPC的非集群内ECS，如果需要和集群互访，访问会做SNAT， Pod源地址是节点IP而非Pod IP。 如果扩展网段没添加过集群节点，那扩展网段的ECS不能访问集群内Pod；扩展网段添加集群节点后，扩展网段的ECS可以访问集群内Pod。

使用须知 快照功能仅支持v1.15及以上版本的集群，且需要安装基于CSI的Everest插件才可以使用。 基于快照创建的云硬盘，其子类型（普通IO/高IO/超高IO）、是否加密、磁盘模式（VBD/SCSI）、共享性(非共享/共享)、容量等都要与快照关联母盘保持一致，这些属性查询和设置出来后不能够修改。 只有可用或正在使用状态的磁盘能创建快照。快照免费试用期间，单个磁盘最大支持创建7个快照。 创建快照功能仅支持使用everest插件提供的存储类（StorageClass名称以csi开头）创建的PVC。使用Flexvolume存储类（StorageClass名为ssd、sas、sata）创建的PVC，无法创建快照。 加密磁盘的快照数据以加密方式存放，非加密磁盘的快照数据以非加密方式存放。

创建快照 使用控制台创建 登录CCE控制台。 单击集群名称进入集群，在左侧选择“容器存储”，在右侧选择“快照与备份”页签。 单击右上角“创建快照”，在弹出的窗口中设置相关参数。 快照名称：填写快照的名称。 选择存储：选择要创建快照的PVC，仅能创建云硬盘类型PVC。 单击“创建”。 使用YAML创建 kind: VolumeSnapshotapiVersion: snapshot.storage.k8s.io/v1beta1metadata: finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection name: cce-disksnap-test namespace: defaultspec: source: persistentVolumeClaimName: pvc-evs-test # PVC的名称，仅能创建云硬盘类型PVC volumeSnapshotClassName: csi-disk-snapclass

使用快照创建PVC 通过快照创建云硬盘PVC时，磁盘类型、磁盘模式、加密属性需和快照源云硬盘保持一致。 使用控制台创建 登录CCE控制台。 单击集群名称进入集群，在左侧选择“容器存储”，在右侧选择“快照与备份”页签。 找到需要创建PVC的快照，单击“创建存储卷声明”，并在弹出窗口中指定PVC的名称。 单击“创建”。 使用YAML创建 apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-test namespace: default annotations: everest.io/disk-volume-type: SSD # 云硬盘类型，需要与快照源云硬盘保持一致 labels: failure-domain.beta.kubernetes.io/region: cn-north-4 failure-domain.beta.kubernetes.io/zone: cn-north-4bspec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: csi-disk dataSource: name: cce-disksnap-test # 快照的名称 kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io

default-secret default-secret的类型为kubernetes.io/dockerconfigjson，其data内容是登录SWR镜像仓库的凭据，用于从SWR拉取镜像。在CCE中创建工作负载时如果需要从SWR拉取镜像，需要配置imagePullSecrets的取值为default-secret，如下所示。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: - name: default-secret default-secret的data数据会定期更新，且当前的data内容会在一定时间后会过期失效。您可以使用describe命令在default-secret的中查看到具体的过期时间，如下所示。 在使用时请直接使用default-secret，而不要拷贝secret内容重新创建，因为secret里面的凭据会过期，从而导致无法拉取镜像。 $ kubectl describe secret default-secretName: default-secretNamespace: defaultLabels: secret-generated-by=cceAnnotations: temporary-ak-sk-expires-at: 2021-11-26 20:55:31.380909 +0000 UTCType: kubernetes.io/dockerconfigjsonData====.dockerconfigjson: 347 bytes

导入存储池 创建节点时导入 在创建节点时，在存储配置中可以为节点添加数据盘，选择“作为持久存储卷”导入存储池，详情请参见创建节点。 手动导入 如果创建节点时没有导入持久存储卷，或当前存储卷容量不够，可以进行手动导入。 前往ECS控制台为节点添加SCSI类型的磁盘。操作步骤详情请参见新增磁盘。 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“容器存储”，并切换至“存储池”页签。 查看已添加磁盘的节点，选择“导入持久卷”，导入时可以选择写入模式。 线性：线性逻辑卷是将一个或多个物理卷整合为一个逻辑卷，实际写入数据时会先往一个基本物理卷上写入，当存储空间占满时再往另一个基本物理卷写入。 条带化：创建逻辑卷时指定条带化，当实际写入数据时会将连续数据分成大小相同的块，然后依次存储在多个物理卷上，实现数据的并发读写从而提高读写性能。多块卷才能选择条带化。

EmptyDir的类型 CCE提供了如下两种EmptyDir类型： 临时路径：Kubernetes原生的EmptyDir类型，生命周期与容器实例相同，并支持指定内存作为存储介质。容器实例消亡时，EmptyDir会被删除，数据会永久丢失。 本地临时卷：本地临时存储卷将节点的本地数据盘通过LVM组成存储池（VolumeGroup），然后划分LV作为EmptyDir的存储介质给容器挂载使用，相比原生EmptyDir默认的存储介质类型性能更好。

临时卷介绍 当有些应用程序需要额外的存储，但并不关心数据在重启后是否仍然可用。 例如，缓存服务经常受限于内存大小，而且可以将不常用的数据转移到比内存慢的存储中，对总体性能的影响并不大。另有些应用程序需要以文件形式注入的只读数据，比如配置数据或密钥。 Kubernetes中的临时卷（Ephemeral Volume），就是为此类场景设计的。临时卷会遵从Pod的生命周期，与 Pod一起创建和删除。 Kubernetes中常用的临时卷： EmptyDir：Pod启动时为空，存储空间来自本地的kubelet根目录（通常是根磁盘）或内存。EmptyDir是从节点临时存储中分配的，如果来自其他来源（如日志文件或镜像分层数据）的数据占满了临时存储，可能会发生存储容量不足的问题。 ConfigMap：将ConfigMap类型的Kubernetes数据以数据卷的形式挂载到Pod中。 Secret：将Secret类型的Kubernetes数据以数据卷的形式挂载到Pod中。

约束与限制 安全容器不支持使用对象存储卷。 OBS限制单用户创建100个桶，但是CCE使用OBS桶为单个工作负载挂载一个桶，当工作负载数量较多时，容易导致桶数量超过限制，OBS桶无法创建。此种场景下建议直接调用OBS的API或SDK使用OBS，不在工作负载中挂载OBS桶。 使用并行文件系统和对象桶时，挂载点不支持修改属组和权限。 CCE支持通过OBS SDK方式和PVC挂载方式使用OBS并行文件系统，其中PVC挂载方式是通过OBS服务提供的obsfs工具实现。关于obsfs工具的介绍和详细使用方法请参见obsfs简介。每挂载一个并行文件系统对象存储卷，就会产生一个obsfs常驻进程。如下图所示： 图1 obsfs常驻进程 建议为每个obsfs进程预留1G的内存空间，例如4U8G的节点，则建议挂载obsfs并行文件系统的实例不超过8个。 obsfs常驻进程是直接运行在节点上，如果消耗的内存超过了节点上限，则会导致节点异常。例如在4U8G的节点上，运行的挂载并行文件系统卷的实例超过100+，有极大概率会导致节点异常不可用。因此强烈建议控制单个节点上的挂载并行文件系统实例的数量。

升级示例 Deployment的升级可以是声明式的，也就是说只需要修改Deployment的YAML定义即可，比如使用kubectl edit命令将上面Deployment中的镜像修改为nginx:alpine。修改完成后再查询ReplicaSet和Pod，发现创建了一个新的ReplicaSet，Pod也重新创建了。 $ kubectl edit deploy nginx$ kubectl get rsNAME DESIRED CURRENT READY AGEnginx-6f9f58dffd 2 2 2 1mnginx-7f98958cdf 0 0 0 48m$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-6f9f58dffd-tdmqk 1/1 Running 0 1mnginx-6f9f58dffd-tesqr 1/1 Running 0 1m Deployment可以通过maxSurge和maxUnavailable两个参数控制升级过程中同时重新创建Pod的比例，这在很多时候是非常有用，配置如下所示。 spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate 在前面的例子中，由于spec.replicas是2，如果maxSurge和maxUnavailable都为默认值25%，那实际升级过程中，maxSurge允许最多3个Pod存在（向上取整，2*1.25=2.5，取整为3），而maxUnavailable则不允许有Pod Unavailable（向上取整，2*0.75=1.5，取整为2），也就是说在升级过程中，一直会有2个Pod处于运行状态，每次新建一个Pod，等这个Pod创建成功后再删掉一个旧Pod，直至Pod全部为新Pod。

回滚 回滚也称为回退，即当发现升级出现问题时，让应用回到老的版本。Deployment可以非常方便的回滚到老版本。 例如上面升级的新版镜像有问题，可以执行kubectl rollout undo命令进行回滚。 $ kubectl rollout undo deployment nginxdeployment.apps/nginx rolled back Deployment之所以能如此容易的做到回滚，是因为Deployment是通过ReplicaSet控制Pod的，升级后之前ReplicaSet都一直存在，Deployment回滚做的就是使用之前的ReplicaSet再次把Pod创建出来。Deployment中保存ReplicaSet的数量可以使用revisionHistoryLimit参数限制，默认值为10。

跨VPC访问 跨VPC访问通常采用对等连接等方法打通VPC。 容器隧道网络只需将节点网络与对端VPC打通，容器自然就能访问对端VPC。 云原生网络2.0与容器隧道网络类似，将容器所在子网网段与对端VPC打通即可。 VPC网络由于容器网段独立，除了要打通VPC网段，还要打通容器网段。 例如有如下两个VPC。 vpc-demo：网段为192.168.0.0/16，集群在vpc-demo内，容器网段为10.0.0.0/16。 vpc-demo2：网段为10.1.0.0/16。 创建一个名为peering-demo的对等连接（本端为vpc-demo，对端为vpc-demo2），注意对端VPC的路由添加容器网段。 这样配置后，在vpc-demo2中就能够访问容器网段10.0.0.0/16。具体访问时要关注安全组配置，打通端口配置。

升级参数说明 参数 说明 限制 最大浪涌（maxSurge） 与spec.replicas相比，可以有多少个Pod存在，默认值是25%。 比如spec.replicas为 4，那升级过程中就不能超过5个Pod存在，即按1个的步长升级，实际升级过程中会换算成数字，且换算会向上取整。这个值也可以直接设置成数字。 仅Deployment支持配置。 最大无效实例数（maxUnavailable） 与spec.replicas相比，可以有多少个Pod失效，也就是删除的比例，默认值是25%。 比如spec.replicas为4，那升级过程中就至少有3个Pod存在，即删除Pod的步长是1。同样这个值也可以设置成数字。 仅Deployment支持配置。 实例可用最短时间（minReadySeconds） 指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。 - 最大保留版本数（revisionHistoryLimit） 用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 kubectl get rs 的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet， 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。 - 升级最大时长（progressDeadlineSeconds） 指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器将持续重试 Deployment。 将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。 如果指定，则此字段值需要大于 .spec.minReadySeconds 取值。 - 缩容时间窗（terminationGracePeriodSeconds） 优雅删除时间，默认为30秒，删除Pod时发送SIGTERM终止信号，然后等待容器中的应用程序终止执行，如果在terminationGracePeriodSeconds时间内未能终止，则发送SIGKILL的系统信号强行终止。 -

VPC内访问 根据集群容器网络模型不同，从容器访问内部网络有不同表现。 容器隧道网络 容器隧道网络在节点网络基础上通过隧道封装网络数据包，容器访问同VPC下其他资源时，只要节点能访问通，容器就能访问通。如果访问不通，需要确认对端资源的安全组配置是否能够允许容器所在节点访问。 云原生网络2.0 云原生网络2.0模型下，容器直接从VPC网段内分配IP地址，容器网段是节点所在VPC的子网，容器与VPC内其他地址天然能够互通。如果访问不通，需要确认对端资源的安全组配置是否能够允许容器网段访问。 VPC网络 VPC网络使用了VPC路由功能来转发容器的流量，容器网段与节点VPC不在同一个网段，容器访问同VPC下其他资源时，需要对端资源的安全组能够允许容器网段访问。 例如集群节点所在网段为192.168.10.0/24，容器网段为172.16.0.0/16。 VPC下（集群外）有一个地址为192.168.10.52的ECS，其安全组规则仅允许集群节点的IP网段访问。 此时如果从容器中ping 192.168.10.52，会发现无法ping通。 kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh/ # ping 192.168.10.25PING 192.168.10.25 (192.168.10.25): 56 data bytes^C--- 192.168.10.25 ping statistics ---104 packets transmitted, 0 packets received, 100% packet loss 在安全组放通容器网段172.16.0.0/16访问。 此时再从容器中ping 192.168.10.52，会发现可以ping通。 $ kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh/ # ping 192.168.10.25PING 192.168.10.25 (192.168.10.25): 56 data bytes64 bytes from 192.168.10.25: seq=0 ttl=64 time=1.412 ms64 bytes from 192.168.10.25: seq=1 ttl=64 time=1.400 ms64 bytes from 192.168.10.25: seq=2 ttl=64 time=1.299 ms64 bytes from 192.168.10.25: seq=3 ttl=64 time=1.283 ms^C--- 192.168.10.25 ping statistics ---4 packets transmitted, 4 packets received, 0% packet loss

容器访问内网不通的定位方法 如前所述，从容器中访问内部网络不通的情况可以按如下路径排查： 查看要访问的对端服务器安全组规则，确认是否允许容器访问。 容器隧道网络模型需要放通容器所在节点的IP地址 VPC网络模型需要放通容器网段 云原生网络2.0需要放通容器所在子网网段 查看要访问的对端服务器是否设置了白名单，如DCS的Redis实例，需要添加白名单才允许访问。添加容器和节点网段到白名单后可解决问题。 查看要访问的对端服务器上是否安装了容器引擎，是否存在与CCE中容器网段冲突的情况。如果有网络冲突，会导致无法访问。

访问其他云服务 与CCE进行内网通信的与服务常见服务有：RDS、DCS、Kafka、RabbitMQ、ModelArts等。 访问其他云服务除了上面所说的VPC内访问和跨VPC访问的网络配置外，还需要关注所访问的云服务是否允许外部访问，如DCS的Redis实例，需要添加白名单才允许访问。通常这些云服务会允许同VPC下IP访问，但是VPC网络模型下容器网段与VPC网段不同，需要特殊处理，将容器网段加入到白名单中。

默认kernel.pid_max说明 CCE在2022年1月底将1.17及以上集群的节点公共操作系统EulerOS 2.5、CentOS 7.6、Ubuntu 18.04镜像kernel.pid_max默认值调整为4194304，满足如下两个条件节点的kernel.pid_max值为4194304。 集群版本：1.17.17及以上版本 节点创建时间：2022年1月30日之后 如果不满足如上两个条件，EulerOS 2.5、CentOS 7.6、Ubuntu 18.04上kernel.pid_max默认值32768。 表1 节点kernel.pid_max默认值 操作系统 1.17.9及以下版本集群 1.17.17及以上版本集群 2022年1月30日及之前创建的节点 2022年1月30日之后创建的节点 EulerOS 2.5 32768 32768 4194304 CentOS 7.6 32768 32768 4194304 Ubuntu 18.04 不涉及 32768 4194304 EulerOS 2.3 57344 57344 57344 EulerOS 2.9 不涉及 4194304 4194304 修改建议 EulerOS 2.3：所有节点都涉及，建议您将kernel.pid_max取值修改为4194304，具体方法请参见修改节点kernel.pid_max。且后续创建节点和节点池时配置安装前脚本修改kernel.pid_max，具体方法请参见配置节点池kernel.pid_max和创建节点时配置kernel.pid_max EulerOS 2.5、CentOS 7.6、Ubuntu 18.04： 对于1.17.17及以上版本集群2022年1月30日及之前创建的节点，建议您将kernel.pid_max取值修改为4194304，具体方法请参见修改节点kernel.pid_max。 对于1.17.9及以下版本集群 存量节点建议您将kernel.pid_max取值修改为4194304，具体方法请参见修改节点kernel.pid_max。 如果新创建节点和节点池，建议配置安装前脚本修改kernel.pid_max，具体方法请参见配置节点池kernel.pid_max和创建节点时配置kernel.pid_max。

创建存储库 这里的备份存储库是指 E-Backup 用于获取和检测后端 对象存储服务 相关信息的 K8s 资源对象。 apiVersion: velero.io/v1kind: BackupStorageLocationmetadata: name: backup-location-001 namespace: velero #必须和E-Backup处于同一namespacespec: config: endpoint: obs.{regionname}.myhuaweicloud.com # OBS的endpoint credential: name: secret-secure-opaque # 此前创建的secret的名字 key: cloud # secret.data中的key值 objectStorage: bucket: tools-cce # OBS中的桶名 prefix: for-backup # 子路径名 provider: huawei # 使用OBS服务 除了 prefix 字段为选填外，其他字段必填。provider 为固定值 huawei。 endpoint 可以到地区和终端节点获取，都需要保证集群内各节点可访问该地址。当endpoint 不带协议头时（http或者https），默认启用 https。 credential中的 name 和 key 需要配置正确，否则 E-Backup 无法访问后端存储库。 创建完成后等待30s用于备份存储库的检查和同步等工作，随后查看该备份存储库状态是否可用，PHASE 为 Available 表示可用，其他表示不可用。 $ kubectl get backupstoragelocations.velero.io backup-location-001 -n velero NAME PHASE LAST VALIDATED AGE DEFAULTbackup-location-001 Available 23s 23m 此处如果PHASE 长时间没有Available，可通过查看E-Backup的日志定位问题。E-Backup安装后会在velero命名空间创建一个名为velero的工作负载，查看velero的日志即可。

删除备份 删除集群中创建的备份对象及其相关对象（比如：Backup/Restore/Schedule等），并且将后端存储库中的备份内容删除，适用于产生大量备份数据时进行的清理工作。 编辑 DeleteBackupRequest 模板，如下所示，随后通过 kubectl create 命令创建。 apiVersion: velero.io/v1kind: DeleteBackupRequestmetadata: name: backup-001-delete namespace: velerospec: backupName: backup-001 # 指定要删除的备份名 查看状态。 $ kubectl -n velero get deletebackuprequests backup-001-delete -o yaml | grep " phase" phase: InProgress InProgress：删除任务正在进行中。 Processed：删除任务已经被处理过。 Processed 状态只意味着 E-Backup 处理过该任务，但是不一定能够完成该任务。可以通过查看 deletebackuprequest.status.errors 字段查看执行删除任务期间出现的错误。如果 E-Backup 正确完整地处理完删除任务，则该 deletebackuprequest 对象本身也会被删除。 后端存储库（OBS桶）中的内容不要人为进行手动删除。

周期备份 操作后会基于配置以一定的周期重复性地执行备份过程，比较适用于容灾。 编辑 Schedule 模板，如下所示，随后通过 kubectl create 命令创建。用户可以自行按照需要给 Schedule 模板打上 label，Schedule 上的 label 都会打到通过 schedule 创建的 backup 上。Schedule 创建到集群后，会立即执行一次备份，后续按照设定的定时周期重复执行备份过程。 apiVersion: velero.io/v1kind: Schedulemetadata: name: schedule-backup-001 namespace: velerospec: schedule: 0 */10 * * * template: runMode: Normal hooks: {} includedNamespaces: - nginx - mysql labelSelector: matchExpressions: - key: direction operator: In values: - back - front matchLabels: app: nginx backup: velero storageLocation: backup-location-001 ttl: 720h0m0s 参数说明如下。 schedule：创建的定时表达式，指定备份的周期执行时间。支持 @every格式 和 Linux标准cron表达式。 @every NUnit：其中N表示一个正整数，Unit可以为s, m, h，表示每隔N个Unit时间触发一次，例如：@every 2h30m，每隔2小时30分执行一次。 标准cron表达式：采用五子表达式，分别是 Minute，Hour，Day-of-Month，Month，Day-of-Week。 template：备份的模板，与备用应用（立即备份）中spec一致。

准备密钥 获取访问密钥。 登录CCE控制台，在右上角用户名下选择“我的凭证”，在左侧选择“访问密钥”，单击“新增访问密钥”。 创建密钥文件，并通过 base64 格式化成字符串。 # 创建密钥文件$ vi credential-for-huawei-obsHUAWEI_CLOUD_AC CES S_KEY_ID=your_access_keyHUAWEI_CLOUD_SECRET_ACCESS_KEY=your_secret_key# 使用 base64 格式化字符串$ base64 -w 0 credential-for-huawei-obsXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHWOBS 创建Secret。 按如下YAML文件创建Secret。 apiVersion: v1kind: Secretmetadata: labels: secret.everest.io/backup: 'true' #标识该secret用于E-Backup访问备份存储库 name: secret-secure-opaque namespace: velero #必须和E-Backup置于同一namespace，取值必须为velerotype: cfe/secure-opaquedata: # credential文件经过base64编码后得到的字符串 cloud: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHWOBS secret 所在 namespace 必须和 E-Backup 实例所在namespace一致，即 velero。 secret.data 中存储的是访问对象存储服务的密钥，其中 key 必须为 cloud，而 value 为2中通过 base64 编码得到的字符串。一般通过 base64 编码后显示的字符串会有换行符，请在写入 secret.data 中时手动去除这些换行符。 secret 需要打上标签“secret.everest.io/backup: true”，标识该 secret 是用于备份存储库的管理。

修改节点单进程最大文件句柄数 登录节点，查看/etc/security/limits.conf文件。 cat /etc/security/limits.conf 节点单进程最大文件句柄数通过以下参数设置： ...root soft nofile 65535root hard nofile 65535* soft nofile 65535* hard nofile 65535 通过sed命令修改最大文件句柄数，其中65535为最大文件句柄数的建议取值。EulerOS 2.3节点/etc/security/limits.conf中没有nofile相关的默认配置，因此不能通过sed命令进行修改。 sed -i "s/nofile.[0-9]*$/nofile 65535/g" /etc/security/limits.conf 重新登录节点，执行以下命令检查是否修改成功，当返回与修改值一致时说明修改正确。 # ulimit -n65535

修改容器单进程最大文件句柄数 登录节点，查看/usr/lib/systemd/system/docker.service文件。 CentOS/EulerOS系统： cat /usr/lib/systemd/system/docker.service Ubuntu系统： cat /lib/systemd/system/docker.service LimitNOFILE或LimitNPROC参数设置为infinity时，表示容器单进程最大文件句柄数为1048576。 容器单进程最大文件句柄数通过以下参数设置： ...LimitNOFILE=1048576LimitNPROC=1048576... 执行如下命令修改两个参数，其中1048576为最大文件句柄数的建议取值。 修改容器最大文件句柄数将会重启docker进程，请知悉。 CentOS/EulerOS系统： sed -i "s/LimitNOFILE=[0-9a-Z]*$/LimitNOFILE=1048576/g" /usr/lib/systemd/system/docker.service;sed -i "s/LimitNPROC=[0-9a-Z]*$/LimitNPROC=1048576/g" /usr/lib/systemd/system/docker.service && systemctl daemon-reload && systemctl restart docker Ubuntu系统： sed -i "s/LimitNOFILE=[0-9a-Z]*$/LimitNOFILE=1048576/g" /lib/systemd/system/docker.service;sed -i "s/LimitNPROC=[0-9a-Z]*$/LimitNPROC=1048576/g" /lib/systemd/system/docker.service && systemctl daemon-reload && systemctl restart docker 查看容器单进程最大文件句柄数，当返回与修改值一致时说明修改正确。 # cat /proc/`pidof dockerd`/limits | grep filesMax open files 1048576 1048576 files

节点系统参数可优化列表 CCE提供默认的节点系统参数在某些用户场景下可能出现性能瓶颈，因此用户可对部分节点系统参数进行自定义优化，节点系统参数如节点系统参数可优化列表所示。 修改节点系统参数具有一定的风险，需要您对Linux命令和Linux系统知识具有较高程度的了解，避免误操作引起节点故障。 表1中的参数已经过测试验证，请勿自行修改其他参数以免引起节点故障。 修改节点系统参数的命令仅在使用公共镜像时有效，使用私有镜像时本文中提供的命令仅供参考。 节点重启后需执行sysctl -p用于刷新参数值。 表1 系统参数可优化列表 参数名称 参数位置 说明 参考文档 kernel.pid_max /etc/sysctl.conf 节点进程 ID数量上限。 查看参数： sysctl kernel.pid_max 修改节点进程 ID数量上限kernel.pid_max RuntimeMaxUse /etc/systemd/journald.conf 节点日志缓存内存占用量上限，若不配置长时间运行会占用较大内存。 查看参数： cat /etc/systemd/journald.conf | grep RuntimeMaxUse 修改节点日志缓存内存占用量上限RuntimeMaxUse Openfiles /etc/security/limits.conf 节点单进程最大文件句柄数，可视业务情况调整。 查看参数： ulimit -n 修改节点单进程最大文件句柄数 （Openfiles容器内部） LimitNOFILE LimitNPROC CentOS/EulerOS系统： /usr/lib/systemd/system/docker.service Ubuntu系统： /lib/systemd/system/docker.service 容器内部单进程最大文件句柄数，可视业务情况调整。 查看参数： cat /proc/`pidof dockerd`/limits | grep files 修改容器单进程最大文件句柄数 file-max /etc/sysctl.conf 系统整体最大文件句柄数，可视业务情况调整。 查看参数： sysctl fs.file-max 修改节点系统级最大文件句柄数 nf_conntrack_buckets nf_conntrack_max /etc/sysctl.conf 连接跟踪表容量，可视业务场景调整。 计算桶占用率= [nf_conntrack_count] / [nf_conntrack_buckets]。 通过调整buckets值，将占用率调整至0.7以下。 查看参数： sysctl net.netfilter.nf_conntrack_countsysctl net.netfilter.nf_conntrack_bucketssysctl net.netfilter.nf_conntrack_max 修改节点内核参数 net.netfilter.nf_conntrack_tcp_timeout_close /etc/sysctl.conf 连接跟踪表里处于close状态连接的表项的过期时间，缩短过期时间可加快回收。 查看参数： sysctl net.netfilter.nf_conntrack_tcp_timeout_close net.netfilter.nf_conntrack_tcp_be_liberal /etc/sysctl.conf 参数值为0或1。 0：表示关闭，所有不在TCP窗口中的RST包都被标志为无效。 1：表示开启，只有不在TCP窗口内的RST包被标志为无效。容器场景下，开启这个参数可以避免NAT过的TCP连接带宽受限。 查看参数： sysctl net.netfilter.nf_conntrack_tcp_be_liberal tcp_keepalive_time /etc/sysctl.conf TCP超时时长，即发送keepalive探测消息的间隔时间。参数值过大可能导致TCP挥手时间过长，长时间下造成大量连接卡在Close_wait阶段，耗尽系统资源。 查看参数： sysctl net.ipv4.tcp_keepalive_time tcp_max_syn_backlog /etc/sysctl.conf TCP最大半连接数，SYN_RECV 队列中的最大连接数。 查看参数： sysctl net.ipv4.tcp_max_syn_backlog tcp_max_tw_buckets /etc/sysctl.conf 指定任何时候允许存在的处于“time-wait”状态的最大套接字数，参数值过大时易耗尽节点资源。 查看参数： sysctl net.ipv4.tcp_max_tw_buckets net.core.somaxconn /etc/sysctl.conf TCP最大连接数，ESTABLISHED 队列的最大大小，参数值过小时极易不足。 查看参数： sysctl net.core.somaxconn max_user_instances /etc/sysctl.conf 每个用户允许的最大 inotify 实例数，参数值过小时容器场景下极易不足。 查看参数： sysctl fs.inotify.max_user_instances max_user_watches /etc/sysctl.conf 所有监视实例的最大目录数，参数值过小时容器场景极易不足。 查看参数： sysctl fs.inotify.max_user_watches netdev_max_backlog /etc/sysctl.conf 网络协议栈收包队列大小，参数值过小时极易不足。 查看参数： sysctl net.core.netdev_max_backlog net.core.wmem_max net.core.rmem_max /etc/sysctl.conf 收发缓冲区内存大小（字节），参数值过小时大文件场景下易不足。 查看参数： sysctl net.core.wmem_maxsysctl net.core.rmem_max net.ipv4.neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh2 net.ipv4.neigh.default.gc_thresh3 /etc/sysctl.conf ARP表项的垃圾回收调优。 查看参数： sysctl net.ipv4.neigh.default.gc_thresh1sysctl net.ipv4.neigh.default.gc_thresh2sysctl net.ipv4.neigh.default.gc_thresh3 vm.max_map_count /etc/sysctl.conf 参数值过小时，安装elk时会提示不足。 查看参数： sysctl vm.max_map_count 父主题： 节点系统参数优化

使用CronHPA直接调整Deployment实例数量 CronHPA还可以单独调整关联Deployment，定时调整Deployment的实例数，使用方法如下。 apiVersion: autoscaling.cce.io/v2alpha1kind: CronHorizontalPodAutoscalermetadata: name: ccetest namespace: defaultspec: scaleTargetRef: # 关联Deployment apiVersion: apps/v1 kind: Deployment name: nginx rules: - ruleName: "scale-down" schedule: "08 * * * *" # 指定任务运行时间与周期，参数格式请参见Cron，例如0 * * * * 或@hourly。 targetReplicas: 1 disable: false - ruleName: "scale-up" schedule: "05 * * * *" targetReplicas: 3 disable: false

Helm v2与Helm v3的差异及适配方案 随着Helm v2 发布最终版本Helm 2.17.0，Helm v3 现在已是 Helm 开发者社区支持的唯一标准。为便于管理，建议用户尽快将模板切换至Helm v3格式。 当前社区从Helm v2演进到Helm v3，主要有以下变化： 移除tiller Helm v3 使用更加简单和灵活的架构，移除了 tiller，直接通过kubeconfig连接apiserver，简化安全模块，降低了用户的使用壁垒。 改进了升级策略，采用三路策略合并补丁 Helm v2 使用双路策略合并补丁。在升级过程中，会对比最近一次发布的chart manifest和本次发布的chart manifest的差异，来决定哪些更改会应用到Kubernetes资源中。如果更改是集群外带的（比如通过kubectl edit），则修改不会被Helm识别和考虑。结果就是资源不会回滚到之前的状态。 Helm v3 使用三路策略来合并补丁，Helm在生成一个补丁时，会考虑之前老的manifest的活动状态。因此，Helm在使用老的chart manifest生成新补丁时会考虑当前活动状态，并将其与之前老的 manifest 进行比对，并再比对新的 manifest 是否有改动，并进行自动补全，以此来生成最终的更新补丁。 详情及示例请见Helm官方文档：https://v3.helm.sh/docs/faq/changes_since_helm2 默认存储驱动程序更改为secrets Helm v2 默认情况下使用 ConfigMaps 存储发行信息，而在 Helm v3 中默认使用 Secrets。 发布名称限制在namespace范围内 Helm v2 只使用tiller 的namespace 作为release信息的存储，这样全集群的release名字都不能重复。Helm v3只会在release安装的所在namespace记录对应的信息，这样release名称可在不同命名空间重用。应用和release命名空间一致。 校验方式改变 Helm v3 对模板格式的校验更加严格，如Helm v3 将chart.yaml的apiVersion从v1切换到v2，针对Helm v2的chart.yaml，强要求指定apiVersion为v1。可安装Helm v3客户端后，通过执行helm lint命令校验模板格式是否符合v3规范。 适配方案：根据Helm官方文档 https://helm.sh/docs/topics/charts/适配Helm v3模板，apiVersion字段必填。 废弃crd-install Helm v3删除了crd-install hook， 并用chart中的crds目录替换。需要注意的是，crds目录中的资源只有在release安装时会部署，升级时不会更新，删除时不会卸载crds目录中的资源。若crd已存在，则重复安装不会报错。 适配方案：根据Helm官方文档 https://helm.sh/docs/chart_best_practices/custom_resource_definitions/, 当前可使用crds目录或者将crd定义单独放入chart。考虑到目前不支持使用Helm升级或删除CRD，推荐分隔chart，将CRD定义放入chart中，然后将所有使用该CRD的资源放到另一个 chart中进行管理。 未通过helm创建的资源不强制update，releaes默认不强制升级 Helm v3强制升级逻辑变化，不再是升级失败后走删除重建，而是直接走put更新逻辑。因此当前CCE release升级默认使用非强制更新逻辑，无法通过Patch更新的资源将导致release升级失败。若环境存在同名资源且无Helm V3的归属标记app.kubernetes.io/managed-by: Helm，则会提示资源冲突。 适配方案：删除相关资源，并通过Helm创建。 Release history数量限制更新 为避免release 历史版本无限增加，当前release升级默认只保留最近10个历史版本。 更多变化和详细说明请参见Helm官方文档 Helm v2与Helm v3的区别：https://v3.helm.sh/docs/faq/changes_since_helm2 Helm v2如何迁移到Helm v3：https://helm.sh/docs/topics/v2_v3_migration 父主题： 模板（Helm Chart）

操作步骤 登录CCE控制台，在左侧导航栏中选择“集群管理”。 单击集群名称，查看“集群信息”页面。 在“网络信息”中单击“节点默认安全组”后的按钮。 图1 节点默认安全组 选择一个已有的安全组，并确认安全组规则满足集群要求后，单击“确定”。 请确认选择的安全组设置了正确的端口规则，否则将无法成功创建节点。安全组需要满足的端口规则根据集群类别存在差异，详情请参见集群安全组规则配置。 新安全组只对新创建或纳管的节点生效，存量节点需要手动修改节点安全组规则，即时对存量节点进行重置，也仍会使用原安全组。如需批量修改存量节点的安全组设置，请参考如何批量修改集群node节点安全组？。 图2 编辑节点默认安全组

转换流程（不使用Helm v3客户端） 在CCE节点上下载helm 2to3 转换插件。 wget https://github.com/helm/helm-2to3/releases/download/v0.10.2/helm-2to3_0.10.2_linux_amd64.tar.gz 解压插件包。 tar -xzvf helm-2to3_0.10.2_linux_amd64.tar.gz 模拟转换。 以test-convert实例为例，执行以下命令进行转换的模拟。若出现以下提示，说明模拟转换成功。 # ./2to3 convert --dry-run --tiller-out-cluster -s configmaps test-convertNOTE: This is in dry-run mode, the following actions will not be executed.Run without --dry-run to take the actions described below:Release "test-convert" will be converted from Helm v2 to Helm v3.[Helm 3] Release "test-convert" will be created.[Helm 3] ReleaseVersion "test-convert.v1" will be created. 执行正式转换。若出现以下提示，说明转换成功。 # ./2to3 convert --tiller-out-cluster -s configmaps test-convertRelease "test-convert" will be converted from Helm v2 to Helm v3.[Helm 3] Release "test-convert" will be created.[Helm 3] ReleaseVersion "test-convert.v1" will be created.[Helm 3] ReleaseVersion "test-convert.v1" created.[Helm 3] Release "test-convert" created.Release "test-convert" was converted successfully from Helm v2 to Helm v3.Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 release.v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated over. 转换完成后进行v2 release资源的清理，同样先进行模拟清理，成功后正式清理v2 release资源。 模拟清理： # ./2to3 cleanup --dry-run --tiller-out-cluster -s configmaps --name test-convertNOTE: This is in dry-run mode, the following actions will not be executed.Run without --dry-run to take the actions described below:WARNING: "Release 'test-convert' Data" will be removed. [Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: yHelm v2 data will be cleaned up.[Helm 2] Release 'test-convert' will be deleted.[Helm 2] ReleaseVersion "test-convert.v1" will be deleted. 正式清理： # ./2to3 cleanup --tiller-out-cluster -s configmaps --name test-convertWARNING: "Release 'test-convert' Data" will be removed. [Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: yHelm v2 data will be cleaned up.[Helm 2] Release 'test-convert' will be deleted.[Helm 2] ReleaseVersion "test-convert.v1" will be deleted.[Helm 2] ReleaseVersion "test-convert.v1" d

转换流程（使用Helm v3客户端） 安装Helm v3客户端，参见安装Helm v3。 安装转换插件。 # helm plugin install https://github.com/helm/helm-2to3Downloading and installing helm-2to3 v0.10.2 ...https://github.com/helm/helm-2to3/releases/download/v0.10.2/helm-2to3_0.10.2_linux_amd64.tar.gzInstalled plugin: 2to3 查看已安装的插件，确认插件已安装。 # helm plugin listNAME VERSION DESCRIPTION 2to3 0.10.2 migrate and cleanup Helm v2 configuration and releases in-place to Helm v3 模拟转换。 以test-convert实例为例，执行以下命令进行转换的模拟。若出现以下相关提示，说明模拟转换成功。 # helm 2to3 convert --dry-run --tiller-out-cluster -s configmaps test-convertNOTE: This is in dry-run mode, the following actions will not be executed.Run without --dry-run to take the actions described below:Release "test-convert" will be converted from Helm v2 to Helm v3.[Helm 3] Release "test-convert" will be created.[Helm 3] ReleaseVersion "test-convert.v1" will be created. 执行正式转换。若出现以下提示，说明转换成功。 # helm 2to3 convert --tiller-out-cluster -s configmaps test-convertRelease "test-convert" will be converted from Helm v2 to Helm v3.[Helm 3] Release "test-convert" will be created.[Helm 3] ReleaseVersion "test-convert.v1" will be created.[Helm 3] ReleaseVersion "test-convert.v1" created.[Helm 3] Release "test-convert" created.Release "test-convert" was converted successfully from Helm v2 to Helm v3.Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 release.v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated over. 正式转换成功后，用户可通过helm list查看已转换成功的模板实例。 # helm listNAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSIONtest-convert default 1 2022-08-29 06:56:28.166918487 +0000 UTC deployed test-helmold-1 转换完成后进行V2 release资源的清理，同样先进行模拟清理，成功后正式清理V2 release资源。 模拟清理： # helm 2to3 cleanup --dry-run --tiller-out-cluster -s configmaps --name test-convertNOTE: This is in dry-run mode, the following actions will not be executed.Run without --dry-run to take the actions described below:WARNING: "Release 'test-convert' Data" will be removed. [Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: yHelm v2 data will be cleaned up.[Helm 2] Release 'test-convert' will be deleted.[Helm 2] ReleaseVersion "test-convert.v1" will be deleted. 正式清理： # helm 2to3 cleanup --tiller-out-cluster -s configmaps --name test-convertWARNING: "Release 'test-convert' Data" will be removed. [Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: yHelm v2 data will be cleaned up.[Helm 2] Release 'test-convert' will be deleted.[Helm 2] ReleaseVersion "test-convert.v1" will be deleted.[Helm 2] ReleaseVersion "test-convert.v1" deleted.[Helm 2] Release 'test-convert' deleted.Helm v2 data was cleaned up successfully.