华为云用户手册

后续步骤 将集群添加至容器舰队后，即可对其进行统一管理。 UCS支持对容器舰队内的多个集群实行统一管理，包括为其开启集群联邦能力以创建和管理多集群工作负载、统一治理多集群流量、为多集群配置统一合规策略等能力。 本小节将以四种最常用的UCS功能为例，指导您快速上手UCS的多集群管理能力，请根据业务需求选择您需要参考的入门指导： 在多集群上部署并管理工作负载，具体入门操作请参见创建多集群工作负载。 为多集群统一下发实例，具体入门操作请参见统一下发多集群实例。 统一治理多集群流量，具体入门操作请参见统一治理多集群流量。 实现多集群智能、可视化运维，具体入门操作请参见开启多集群健康监控。

获取KubeConfig文件 登录待添加集群的Master节点。 获取待添加集群的KubeConfig文件。 cat $HOME/.kube/config 默认情况下，自建集群的配置文件路径为Master节点的“$HOME/.kube/config”，如您的集群指定了其他KubeConfig配置文件，请自行更换路径。关于KubeConfig文件的详细说明请参见使用KubeConfig文件组织集群访问。 复制KubeConfig文件内容。 在本地创建一个YAML文件，将上一步中的复制内容粘贴至该文件并保存。

获取资源权限 由于UCS服务的容器集群功能支持CCE集群，因此需要获取访问云容器引擎CCE服务的权限。在您首次登录UCS控制台时，UCS将自动请求获取该权限，从而更好地为您提供服务。 当您同意授权后，UCS将在IAM中创建名为ucs_admin_trust的委托，统一使用系统帐户“op_svc_ucs”对您的CCE及其他云服务资源进行操作，并且授予其Tenant Administrator权限。Tenant Administrator拥有除IAM管理外的全部云服务管理员权限，用于对UCS所依赖的其他云服务资源进行调用。关于资源委托详情，您可参考委托进行了解。 由于UCS对其他云服务有许多依赖，如果没有Tenant Administrator权限，可能会因为某个服务权限不足而影响UCS功能的正常使用。因此在使用UCS服务期间，请不要自行删除或者修改“ucs_admin_trust”委托。 如果误操作，可以参考误删除或修改系统创建的ucs_admin_trust委托，怎么恢复？进行恢复。

创建无状态工作负载 登录UCS控制台，在左侧导航栏中选择“容器舰队”。 在“容器舰队”页签下找到已开通集群联邦的舰队，单击名称进入详情页。 在左侧导航栏中选择“工作负载”，在“无状态负载”页签中单击右上角“镜像创建”。 设置工作负载基本信息。 表1 工作负载基本信息设置 参数 描述 负载类型 选择“无状态负载”。 命名空间 选择工作负载所需部署的命名空间。 描述 输入工作负载的描述信息。 实例数量 设置工作负载中各集群的实例数，默认为2。 设置工作负载容器配置。 工作负载中的Pod内可配置多个容器，您可以单击右侧“添加容器”为Pod配置多个容器并分别进行设置，本例中仅对容器的基本信息进行配置。 基本信息： 表2 基本信息参数说明 参数 说明 容器名称 为容器命名。 镜像名称 单击后方“选择镜像”，选择容器使用的镜像。 镜像版本 选择需要部署的镜像版本。 更新策略 镜像更新/拉取策略。勾选“总是拉取镜像”表示每次都从镜像仓库拉取镜像；如不勾选则优先使用节点已有的镜像，如果没有这个镜像再从镜像仓库拉取。 CPU配额 申请：容器需要使用的最小CPU值，默认0.25Core。 限制：允许容器使用的CPU最大值。建议设容器配额的最高限额，避免容器资源超额导致系统故障。 内存配额 申请：容器需要使用的内存最小值，默认512MiB。 限制：允许容器使用的内存最大值。如果超过，容器会被终止。 初始化容器 选择容器是否作为Init容器。 说明： Init容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。详细说明请参见Init 容器。 单击“下一步：调度与差异化”，对选择的集群进行调度与差异化配置。 表3 集群调度策略参数配置 参数 描述 调度方式 可选择集群权重或自动均衡两种模式。 集群权重：手动设置各集群的权重，工作负载在各集群的实例数将根据设置的权重比例进行分配。 自动均衡：工作负载将根据资源余量在可调度的集群中自动选择集群进行部署。 部署集群 “集群权重”模式下，需手动设置各集群权重值，权重非0的集群将自动勾选为可调度集群，权重为0则表示该集群不可调度。状态非正常的集群无法设置权重。 “自动均衡”模式下，单击集群即可将其勾选为可调度集群。 设置完成后，单击“创建工作负载”，完成创建后，可单击“返回工作负载列表”查看所创建的工作负载。

解决办法 需排查集群配置信息，检查缩容是否满足以下条件： 集群按照环的方式配置，比如4个或5个主机组成一个环，这些主机上的DN主节点、备节点和从节点都部署在这些节点里，这些节点组成一个集群环 ，缩容的最小单元是一个集群环，集群至少有2个环才能支持缩容，缩容按照集群环从后往前缩容节点。 缩容节点不能包含GTM组件，CM Server组件，CN组件。 集群状态为Normal，无其他任务信息。 集群租户账号不能处于只读，冻结，受限状态。 集群非逻辑集群模式。 包周期集群不能处于已过期进入宽限期。

基本信息 策略类型：安全 推荐级别：L3 生效资源类型：Pod 参数： exemptImages: 字符串数组 runAsUser: rule: 字符串 ranges: - min: 整型 max: 整型 runAsGroup: rule: 字符串 ranges: - min: 整型 max: 整型 supplementalGroups: rule: 字符串 ranges: - min: 整型 max: 整型 fsGroup: rule: 字符串 ranges: - min: 整型 max: 整型

策略实例示例 以下策略实例展示了策略定义生效的资源类型，parameters中定义了对runAsUser、runAsGroup、supplementalGroups和fsGroup等字段的约束。 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPAllowedUsers metadata: name: psp-pods-allowed-user-ranges spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: runAsUser: rule: MustRunAs # MustRunAsNonRoot # RunAsAny ranges: - min: 100 max: 200 runAsGroup: rule: MustRunAs # MayRunAs # RunAsAny ranges: - min: 100 max: 200 supplementalGroups: rule: MustRunAs # MayRunAs # RunAsAny ranges: - min: 100 max: 200 fsGroup: rule: MustRunAs # MayRunAs # RunAsAny ranges: - min: 100 max: 200

符合策略实例的资源定义 示例中runAsUser等参数均在范围内，符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-users-allowed labels: app: nginx-users spec: securityContext: supplementalGroups: - 199 fsGroup: 199 containers: - name: nginx image: nginx securityContext: runAsUser: 199 runAsGroup: 199

不符合策略实例的资源定义 示例中runAsUser等参数不在范围内，不符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-users-disallowed labels: app: nginx-users spec: securityContext: supplementalGroups: - 250 fsGroup: 250 containers: - name: nginx image: nginx securityContext: runAsUser: 250 runAsGroup: 250

使用限制 需要创建弹性扩缩容策略的集群至少有一个实例， 如果没有实例则会自动进行扩容。 一个集群一次扩容的实例数的上限为min(max(4，2 * current replicas)，MaxReplicas)个，防止一次性扩容个数过多。 使用HPA需要在集群中安装能够提供Metrics API的插件，如metrics-server或Prometheus。若使用Prometheus，需要将Prometheus注册为Metrics API的服务，详见提供资源指标。

操作步骤 登录集群控制台。 在左侧导航栏中选择“负载伸缩”，并单击右上角“创建HPA策略”。 设置HPA参数。 策略名称：新建策略的名称，命名必须唯一。 命名空间：HPA策略所在的命名空间。 关联工作负载：选择需要创建策略的工作负载。 实例范围：请输入最小实例数和最大实例数。策略触发时，工作负载实例将在此范围内伸缩。 冷却时间：请输入缩容和扩容的冷却时间，单位为分钟，缩容扩容冷却时间不能小于1分钟。 策略成功触发后，在此缩容/扩容冷却时间内，不会再次触发缩容/扩容，目的是等待伸缩动作完成后在系统稳定且集群正常的情况下进行下一次策略匹配。 系统策略：策略规则可基于系统指标。 指标：可选择“CPU利用率”或“内存利用率”。 利用率 = 工作负载Pod的实际使用量 / 申请量。 期望值：请输入期望资源平均利用率。 期望值表示所选指标的期望值，通过向上取整(当前指标值 / 期望值 × 当前实例数)来计算需要伸缩的实例数。 阈值：请输入缩容和扩容阈值。 当指标值大于缩容阈值且小于扩容阈值时，不会触发扩容或缩容。 您设置多条伸缩策略。 自定义策略： 自定义指标名称：选择伸缩策略依赖的自定义指标。 指标来源：表示自定义指标所描述的对象。 期望值：请期望资源平均值。 期望值表示所选指标的期望值，通过向上取整(当前指标值 / 期望值 × 当前实例数)来计算需要伸缩的实例数。 阈值：请输入缩容和扩容阈值。 当指标值大于缩容阈值且小于扩容阈值时，不会触发扩容或缩容。 您设置多条伸缩策略。 集群中未安装系统指标采集插件时，负载伸缩策略将无法生效，详情请参考对Metrics API的支持。 单击“创建”。创建成功后可在HPA策略列表中查看。

安装Metrics Server插件 Metrics Server插件作为集群核心资源监控数据的聚合器，可在您的集群中便捷地进行安装。 使用以下命令安装Metrics Server。 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml 使用以下命令验证Metrics Server是否安装成功。 kubectl get deployment metrics-server -n kube-system 如果输出结果类似于以下内容，则表示安装成功。 NAME READY UP-TO-DATE AVAILABLE AGE metrics-server 1/1 1 1 6m

策略实例示例 以下策略实例展示了策略定义生效的资源类型，pararmeters中定义了允许的组列表allowedGroups和允许的用户列表allowedUsers。 # IMPORTANT: Before deploying this policy, make sure you allow-list any groups # or users that need to deploy workloads to kube-system, such as cluster- # lifecycle controllers, addon managers, etc. Such controllers may need to # update service account names during automated rollouts (e.g. of refactored # configurations). You can allow-list them with the allowedGroups and # allowedUsers properties of the NoUpdateServiceAccount Constraint. apiVersion: constraints.gatekeeper.sh/v1beta1 kind: NoUpdateServiceAccount metadata: name: no-update-kube-system-service-account spec: match: namespaces: ["kube-system"] kinds: - apiGroups: [""] kinds: # You can optionally add "Pod" here, but it is unnecessary because # Pod service account immutability is enforced by the Kubernetes API. - "ReplicationController" - apiGroups: ["apps"] kinds: - "ReplicaSet" - "Deployment" - "StatefulSet" - "DaemonSet" - apiGroups: ["batch"] kinds: # You can optionally add "Job" here, but it is unnecessary because # Job service account immutability is enforced by the Kubernetes API. - "CronJob" parameters: allowedGroups: [] allowedUsers: []

符合策略实例的资源定义 没有更新ServiceAccount，符合策略实例。 # Note: The gator tests currently require exactly one object per example file. # Since this is an update-triggered policy, at least two objects are technically # required to demonstrate it. Due to the gator requirement, we only have one # object below. The policy should allow changing everything but the # serviceAccountName field. kind: Deployment apiVersion: apps/v1 metadata: name: policy-test namespace: kube-system labels: app: policy-test spec: replicas: 1 selector: matchLabels: app: policy-test-deploy template: metadata: labels: app: policy-test-deploy spec: # Changing anything except this field should be allowed by the policy. serviceAccountName: policy-test-sa-1 containers: - name: policy-test image: ubuntu command: - /bin/bash - -c - sleep 99999

MCI的工作原理 MCI的功能主要通过请求转发执行器MCI Controller实现。MCI Controller部署在集群联邦控制面，实时监控资源对象的变化，解析MCI对象定义的规则并负责将请求转发到相应的后端Service。 图2 MCI Controller工作原理 MCI Controller支持在同一个ELB实例（即同一IP）下设置不同域名、端口和转发规则，其工作原理如图2，实现流程如下： 部署人员在集群联邦控制面创建工作负载，并为其配置Service对象。 部署人员在集群联邦控制面创建MCI对象，并在MCI中配置流量访问规则，包括关联的负载均衡器、URL以及访问的后端Service及端口等。 MCI Controller监控到MCI对象发生变化，会根据MCI中定义的规则，在ELB侧重新配置监听器以及后端服务器路由。 当用户进行访问时，流量根据ELB中配置的转发策略被转发到对应的后端Service关联的各个工作负载。

为什么需要MCI 在传统的Kubernetes集群中，每个集群都有其负载均衡器和Ingress，这使得在多个集群之间进行负载均衡和流量路由变得困难。UCS为多集群提供了统一的流量入口MCI（Multi Cluster Ingress），帮助您更加简单高效地跨集群、跨区域进行负载均衡和流量路由，进而提高应用程序的可用性和可靠性。 MCI是一种多集群Ingress资源对象，可以根据指定规则将外部流量路由到多个集群内的Pod。使用MCI，用户可自定义转发规则，完成对访问流量的细粒度划分。图1展示了流量如何从MCI流向集群：从域名 foo.example.com 流入的流量流向了两个集群中带有标签 app:foo 的 Pod，从域名goo.example.com 流入的流量流向了两个集群中具有标签 app:goo的 Pod。 图1 MCI示意图 具体来说，MCI的优势在于： 多集群负载均衡：MCI为用户提供统一入口，将流量分发到多个Kubernetes集群中，与集群所处位置无关。 流量路由：使用MCI，用户可根据不同条件（URL、HTTP头、源IP等）自定义转发规则，将流量路由到不同集群，实现更灵活的流量控制。 高可用：MCI通过健康检查和流量自动切换，实现多集群、多区域的高可用性。 可扩展性：MCI发现和管理多个Kubernetes集群上的应用程序资源，实现应用程序自动扩展和部署。 安全性：MCI支持TLS安全策略和证书管理，保障应用程序的安全性。

策略实例示例 以下策略实例展示了策略定义生效的资源类型。 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPFSGroup metadata: name: psp-fsgroup spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: rule: "MayRunAs" #"MustRunAs" #"MayRunAs", "RunAsAny" ranges: - min: 1 max: 1000

符合策略实例的资源定义 示例中fsGroup设为了500，符合策略实例。 apiVersion: v1 kind: Pod metadata: name: fsgroup-disallowed spec: securityContext: fsGroup: 500 # directory will have group ID 500 volumes: - name: fsgroup-demo-vol emptyDir: {} containers: - name: fsgroup-demo image: busybox command: ["sh", "-c", "sleep 1h"] volumeMounts: - name: fsgroup-demo-vol mountPath: /data/demo

不符合策略实例的资源定义 示例中fsGroup设为了2000，不符合策略实例。 apiVersion: v1 kind: Pod metadata: name: fsgroup-disallowed spec: securityContext: fsGroup: 2000 # directory will have group ID 2000 volumes: - name: fsgroup-demo-vol emptyDir: {} containers: - name: fsgroup-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: - name: fsgroup-demo-vol mountPath: /data/demo

同Region UCS华为云集群迁移流程 在同一地理区域内的华为云UCS管理的Kubernetes集群间进行迁移，实现资源优化、应用升级或其他管理需求。迁移流程如图1所示。 图1 迁移流程 主要包含四个步骤： 集群评估 在这个阶段，您将根据源集群的现状来评估适合迁移的目标集群类型。UCS的kspider工具能够自动收集源集群的信息，包括Kubernetes版本、规模、工作负载、存储等数据，并根据收集到的数据为您提供推荐的目标集群信息。具体请参见集群评估。 存储迁移 在这个阶段，您将把云硬盘的数据迁移到目标AZ。具体请参见存储迁移。 应用备份 在这个阶段，您将对源AZ集群中的应用进行备份。UCS的k8clone工具可以自动收集Kubernetes元数据，并将其以压缩包的形式保存到本地，从而实现集群中应用的备份。具体请参见应用备份。 应用迁移 在这个阶段，您将利用备份数据恢复的方法，将源AZ集群中的应用迁移到目标AZ集群。具体请参见应用迁移。 父主题： 同Region UCS华为云集群迁移

符合策略实例的资源定义 示例中sysctls的name符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-forbidden-sysctls-disallowed labels: app: nginx-forbidden-sysctls spec: containers: - name: nginx image: nginx securityContext: sysctls: - name: net.core.somaxconn value: "1024"

策略实例示例 以下策略实例展示了策略定义生效的资源类型，parameters中的forbiddenSysctls定义了sysctls中不能允许的名称。 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPForbiddenSysctls metadata: name: psp-forbidden-sysctls spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: forbiddenSysctls: # - "*" # * may be used to forbid all sysctls - kernel.*

不符合策略实例的资源定义 示例中sysctls的name（kernel.msgmax）不符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-forbidden-sysctls-disallowed labels: app: nginx-forbidden-sysctls spec: containers: - name: nginx image: nginx securityContext: sysctls: - name: kernel.msgmax value: "65536" - name: net.core.somaxconn value: "1024"

不符合策略实例的资源定义 示例中volumes中的类型（hostPath）不在上述定义的允许范围内，不符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-volume-types-disallowed labels: app: nginx-volume-types spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: /cache name: cache-volume - name: nginx2 image: nginx volumeMounts: - mountPath: /cache2 name: demo-vol volumes: - name: cache-volume hostPath: path: /tmp # directory location on host - name: demo-vol emptyDir: {}

策略实例示例 以下策略实例展示了策略定义生效的资源类型，parameters的volumes字段定义了允许的类型列表。 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPVolumeTypes metadata: name: psp-volume-types spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: volumes: # - "*" # * may be used to allow all volume types - configMap - emptyDir - projected - secret - downwardAPI - persistentVolumeClaim #- hostPath #required for allowedHostPaths - flexVolume #required for allowedFlexVolumes

符合策略实例的资源定义 示例中volumes中的类型均在上述定义的允许范围内，符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-volume-types-allowed labels: app: nginx-volume-types spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: /cache name: cache-volume - name: nginx2 image: nginx volumeMounts: - mountPath: /cache2 name: demo-vol volumes: - name: cache-volume emptyDir: {} - name: demo-vol emptyDir: {}

不符合策略实例的资源定义 示例中allowPrivilegeEscalation的值不为false，不符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-privilege-escalation-disallowed labels: app: nginx-privilege-escalation spec: containers: - name: nginx image: nginx securityContext: allowPrivilegeEscalation: true

策略实例示例 以下策略实例展示了策略定义生效的资源类型。 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPAllowPrivilegeEscalationContainer metadata: name: psp-allow-privilege-escalation-container spec: match: kinds: - apiGroups: [""] kinds: ["Pod"]

符合策略实例的资源定义 示例中allowPrivilegeEscalation的值为false，符合策略实例。 apiVersion: v1 kind: Pod metadata: name: nginx-privilege-escalation-allowed labels: app: nginx-privilege-escalation spec: containers: - name: nginx image: nginx securityContext: allowPrivilegeEscalation: false

符合策略实例的资源定义 ingress配置的hostname不是空白或通配符类型，符合策略实例。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: non-wildcard-ingress spec: rules: - host: 'myservice.example.com' http: paths: - pathType: Prefix path: "/" backend: service: name: example port: number: 80