华为云用户手册

创建CCE集群 clickhouse-operator用于K8s中创建、配置、管理ClickHouse集群 。 本文指导在CCE集群中安装部署clickhouse-operator并举例创建clickhouse集群资源 ，参考文档：https://github.com/Altinity/clickhouse-operator。 clickhouse-operator安装要求K8s版本为1.15.11+，本文使用1.19。 集群类型 CCE集群 集群版本 1.19 Region 上海一 Docker版本 18.09.0.91 网络模型 VPC网络 服务转发模式 iptables 父主题： ClickHouse on CCE部署指南

Simple example 本示例来源于https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/01-simple-layout-01-1shard-1repl.yaml。 yaml文件如下： apiVersion: "clickhouse.altinity.com/v1"kind: "ClickHouseInstallation"metadata: name: "simple-01" 使用如下命令创建： kubectl apply -n test-clickhouse-operator -f https://raw.githubusercontent.com/Altinity/clickhouse-operator/master/docs/chi-examples/01-simple-layout-01-1shard-1repl.yaml 一段时间后，查看资源运行情况： kubectl get pod -n test-clickhouse-operator kubectl get service -n test-clickhouse-operator 连接ClickHouse Database： kubectl -n test-clickhouse-operator exec -ti chi-simple-01-cluster-0-0-0 -- clickhouse-client

Simple Persistent Volume Example 本示例来源于https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/03-persistent-volume-01-default-volume.yaml。 在CCE使用PVC时，yaml文件需做一些适配： 使用云硬盘存储卷EVS 创建storageClass CCE默认支持的csi-disk为SAS类型的云硬盘。 若想使用超高I/O类型的云硬盘，需要创建对应的storageClass。 vim csi-disk-ssd.yaml 复制以下内容： allowVolumeExpansion: trueapiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: csi-disk-ssdparameters: csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io csi.storage.k8s.io/fstype: ext4 everest.io/disk-volume-type: SSD everest.io/passthrough: "true"provisioner: everest-csi-provisionerreclaimPolicy: DeletevolumeBindingMode: Immediate 保存后退出： kubectl create -f csi-disk-ssd.yaml accessModes需填写为ReadWriteOnce。 添加storageClassName: csi-disk-ssd。 使用文件存储卷SFS accessModes需填写为ReadWriteMany。 添加storageClassName: csi-nas。 下面以文件存储卷SFS为例，yaml文件如下： apiVersion: "clickhouse.altinity.com/v1"kind: "ClickHouseInstallation"metadata: name: "pv-simple"spec: defaults: templates: dataVolumeClaimTemplate: data-volume-template logVolumeClaimTemplate: log-volume-template configuration: clusters: - name: "simple" layout: shardsCount: 1 replicasCount: 1 templates: volumeClaimTemplates: - name: data-volume-template spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: csi-nas - name: log-volume-template spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: csi-nas 使用如下命令创建： kubectl -n test-clickhouse-operator create -f 03-persistent-volume-01-default-volume.yaml 一段时间后，查看资源运行情况： kubectl get pvc -n test-clickhouse-operator kubectl get pod -n test-clickhouse-operator 查看存储卷挂载情况： kubectl -n test-clickhouse-operator exec -ti chi-pv-simple-simple-0-0-0 -c clickhouse bash df -h 连接ClickHouse Database： kubectl -n test-clickhouse-operator exec -ti chi-pv-simple-simple-0-0-0 -- clickhouse-client

双架构镜像构建方法 制作双架构镜像，Docker客户端版本需要大于18.03。 构建双架构镜像的本质是先分别构建x86和ARM架构的镜像，然后通过构建双架构的镜像manifest。 例如已经构建好了defaultbackend-linux-amd64:1.5和defaultbackend-linux-arm64:1.5两个镜像，分别是x86架构和ARM架构。 将这两个镜像上传到SWR镜像仓库，如下所示。上传镜像的具体方法请参见客户端上传镜像。 # 给原始amd64镜像defaultbackend-linux-amd64:1.5加tagdocker tag defaultbackend-linux-amd64:1.5 swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-amd64:1.5# 给原始arm64镜像defaultbackend-linux-arm64:1.5加tagdocker tag defaultbackend-linux-arm64:1.5 swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-arm64:1.5# 上传amd64镜像至swr镜像仓库docker push swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-amd64:1.5# 上传arm64镜像至swr镜像仓库docker push swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-arm64:1.5 创建双架构manifest文件并上传。 # 开启DOCKER_CLI_EXPERIMENTALexport DOCKER_CLI_EXPERIMENTAL=enabled# 创建镜像manifest文件docker manifest create --amend --insecure swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend:1.5 swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-arm64:1.5 swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-amd64:1.5# 给镜像manifest文件添加arch信息docker manifest annotate swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend:1.5 swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-amd64:1.5 --arch amd64docker manifest annotate swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend:1.5 swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-arm64:1.5 --arch arm64# 向swr镜像仓库推送镜像manifestdocker manifest push -p --insecure swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend:1.5

亲和性配置说明 CCE在创建节点时，会自动给节点打上kubenetes.io/arch的标签，表示节点架构，如下所示。 kubernetes.io/arch=amd64 取值amd64表示是x86架构，arm64表示是ARM架构。 在创建工作负载时，可以通过配置节点亲和性，将Pod调度到对应架构的节点上。 使用YAML可以通过nodeSelector进行配置，如下所示。 apiVersion: apps/v1kind: Deploymentmetadata: name: testspec: selector: matchLabels: app: test template: metadata: labels: app: test spec: nodeSelector: kubernetes.io/arch: amd64 containers: - name: container0 image: swr.cn-north-4.myhuaweicloud.com/test-namespace/defaultbackend-linux-amd64:1.5 resources: limits: cpu: 250m memory: 512Mi requests: cpu: 250m memory: 512Mi imagePullSecrets: - name: default-secret

解决方案 解决在不同架构的节点使用镜像创建工作负载通常有两种方法： 创建工作负载的时候通过亲和性设置，使用ARM架构镜像时让Pod调度到ARM架构的节点上，使用x86架构镜像时让Pod调度到x86架构的节点上。 构建双架构镜像，同时支持两种架构，当Pod调度到ARM架构节点时拉取ARM架构的镜像，当Pod调度到x86架构节点时拉取x86架构的镜像。双架构镜像的一个特征是镜像可以只使用一个地址，但背后有两个镜像，这样在描述工作负载时，可以使用同一个镜像地址，且不用配置亲和性，工作负载描述文件更简洁更容易维护。

通过kubectl创建MySQL 本步骤指导您通过kubectl创建一个无状态工作负载（Deployment），并通过集群内访问类型Service将负载公开，使得其能在集群内通过Service访问。 请参见通过kubectl连接集群，使用kubectl连接集群。 创建一个名为mysql-deployment.yaml的描述文件。其中，mysql-deployment.yaml为自定义名称，您可以随意命名。 vi mysql-deployment.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: mysql namespace: defaultspec: replicas: 1 selector: matchLabels: app: mysql version: v1 template: metadata: labels: app: mysql version: v1 spec: containers: - name: container-1 image: mysql:5.7 env: - name: MYSQL_ROOT_PASSWORD value: password@123 - name: MYSQL_DATABASE value: database - name: MYSQL_USER value: db_user - name: MYSQL_PASSWORD value: password@123 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi imagePullSecrets: - name: default-secret 创建MySQL。 kubectl apply -f mysql-deployment.yaml 回显如下表示已开始创建deployment。 deployment "mysql" created 查看deployment状态。 kubectl get deployment deployment状态显示为Running，表示deployment已创建成功。 NAME READY UP-TO-DATE AVAILABLE AGE mysql 1/1 1 1 4m5s 创建一个名为mysql-service.yaml的描述文件。其中，mysql-service.yaml为自定义名称，您可以随意命名。 vi mysql-service.yaml apiVersion: v1kind: Servicemetadata: name: mysql namespace: defaultspec: selector: app: mysql version: v1 ports: - name: cce-service-0 targetPort: 3306 nodePort: 0 port: 3306 protocol: TCP type: ClusterIP

部署Wordpress 添加Wordpress官方Repo。 helm repo add bitnami https://charts.bitnami.com/bitnami 执行如下命令，创建WordPress应用。 helm install myblog bitnami/wordpress \ --set mariadb.primary.persistence.enabled=true \ --set mariadb.primary.persistence.storageClass=csi-disk \ --set mariadb.primary.persistence.size=10Gi \ --set persistence.enabled=false Mariadb使用持久化存储卷保存数据。持久化存储选用云硬盘，大小为10 GiB，并通过配置StorageClassName自动化创建。 WordPress不需要进行数据持久化，数据卷persistence.enabled配置为false。 命令执行后回显类似如下。 coalesce.go:223: warning: destination for mariadb.networkPolicy.egressRules.customRules is a table. Ignoring non-table value ([])NAME: myblogLAST DEPLOYED: Mon Mar 27 11:47:58 2023NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:CHART NAME: wordpressCHART VERSION: 15.2.57APP VERSION: 6.1.1** Please be patient while the chart is being deployed **Your WordPress site can be accessed through the following DNS name from within your cluster: myblog-wordpress.default.svc.cluster.local (port 80)To access your WordPress site from outside the cluster follow the steps below:1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w myblog-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default myblog-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin"2. Open a browser and access WordPress using the obtained URL.3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default myblog-wordpress -o jsonpath="{.data.wordpress-password}" | base64 -d) 回显中告诉了如何获取外部访问地址和登录WordPress后台的用户及密码。

删除WordPress应用 执行如下命令可删除WordPress应用。 helm delete myblog 回显如下。 release "myblog" uninstalled 删除WordPress中mariadb组件使用的存储PVC。 kubectl delete pvc data-myblog-mariadb-0 回显如下。 persistentvolumeclaim "data-myblog-mariadb-0" deleted

排查项三：带云硬盘卷的Deployment的副本数大于1 问题描述： 创建Pod失败，并报“添加存储失败”的事件，事件信息如下。 Multi-Attach error for volume "pvc-62a7a7d9-9dc8-42a2-8366-0f5ef9db5b60" Volume is already used by pod(s) testttt-7b774658cb-lc98h 问题定位： 查看Deployment的副本数是否大于1。 Deployment中使用EVS存储卷时，副本数只能为1。若用户在后台指定Deployment的实例数为2以上，此时CCE并不会限制Deployment的创建。但若这些实例Pod被调度到不同的节点，则会有部分Pod因为其要使用的EVS无法被挂载到节点，导致Pod无法启动成功。 解决方案： 使用EVS的Deployment的副本数指定为1，或使用其他类型存储卷。

排查项二：存储中是否同时存在多条权限相关的配置 如果您挂载的存储中内容太多，同时又配置了以下几条配置，最终会由于逐个修改文件权限，而导致挂载时间过长。 问题定位： Securitycontext字段中是否包含runAsuser/fsGroup。securityContext是kubernetes中的字段，即安全上下文，它用于定义Pod或Container的权限和访问控制设置。 启动命令中是否包含ls、chmod、chown等查询或修改文件权限的操作。 解决建议： 请根据您的业务需求，判断是否需要修改。

排查项四：EVS磁盘文件系统损坏 问题描述： 创建Pod失败，出现类似信息，磁盘文件系统损坏。 MountVolume.MountDevice failed for volume "pvc-08178474-c58c-4820-a828-14437d46ba6f" : rpc error: code = Internal desc = [09060def-afd0-11ec-9664-fa163eef47d0] /dev/sda has file system, but it is detected to be damaged 解决方案： 在EVS中对磁盘进行备份，然后执行如下命令修复文件系统。 fsck -y {盘符}

通过API或kubectl操作CCE集群，创建的资源是否能在控制台展示？ 在CCE控制台，暂时不支持显示的kubernetes资源有：DaemonSet、 ReplicationController、ReplicaSets、Endpoints等。 若需要查询这些资源，请通过kubectl命令进行查询。 此外，Deployment、Statefulset、Service和Pod资源需满足以下条件，才能在控制台显示： Deployment和Statefulset：标签中必须至少有一个标签是以"app"为key的。 Pod：只有创建了无状态工作负载（Deployment）和有状态工作负载（StatefulSet）后，对应Pod实例才会在工作负载详情页的“实例列表”页签中显示。 Service：Service当前在无状态工作负载（Deployment）和有状态工作负载（StatefulSet）详情页的“访问方式”页签中显示。 此处的显示需要Service与工作负载有一定的关联： 工作负载中的一个标签必须是以"app"为key。 Service的标签和工作负载的标签保持一致。 父主题： API&kubectl

为什么访问部署的应用时浏览器返回404错误码？ CCE服务本身在浏览器中访问应用时不会返回任何的错误码，请优先排查自身业务。 404 Not Found 如果404的返回如下图所示，说明这个返回码是ELB返回的，说明ELB找不到相关的转发策略。请排查相关的转发规则等。 图1 404:ALB 如果404的返回如下图所示，说明这个返回码是由nginx（客户业务）返回，请排查客户自身业务问题。 图2 404:nginx/1.**.* 父主题： 网络异常

CCE集群中工作负载镜像的拉取策略？ 容器在启动运行前，需要镜像。镜像的存储位置可能会在本地，也可能会在远程镜像仓库中。 Kubernetes配置文件中的imagePullPolicy属性是用于描述镜像的拉取策略的，如下： Always：总是拉取镜像。 imagePullPolicy: Always IfNotPresent：本地有则使用本地镜像，不拉取。 imagePullPolicy: IfNotPresent Never：只使用本地镜像，从不拉取，即使本地没有。 imagePullPolicy: Never 说明如下： 如果设置为Always ，则每次容器启动或者重启时，都会从远程仓库拉取镜像。 如果省略imagePullPolicy，策略默认为Always。 如果设置为IfNotPreset，有下面两种情况： 当本地不存在所需的镜像时，会从远程仓库中拉取。 如果需要的镜像和本地镜像内容相同，只不过重新打了tag。此tag镜像本地不存在，而远程仓库存在此tag镜像。这种情况下，Kubernetes并不会拉取新的镜像。 父主题： 其他

解决方法 一般情况下，您需要从证书提供商处获取有效的合法证书。如果您需要在测试环境下使用，您可以自建证书和私钥，方法如下： 自建的证书通常只适用于测试场景，使用时界面会提示证书不合法，影响正常访问，建议您选择手动上传合法证书，以便通过浏览器校验，保证连接的安全性。 自己生成tls.key。 openssl genrsa -out tls.key 2048 将在当前目录生成一个tls.key的私钥。 用此私钥去签发生成自己的证书。 openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/O=Devops/CN=example.com -days 3650 生成的私钥格式必须为： ----BEGIN RSA PRIVATE KEY-----……………………………………………..-----END RSA PRIVATE KEY----- 生成的证书格式必须为： -----BEGIN CERTIFICATE-----……………………………………………………………-----END CERTIFICATE----- 导入证书。 新建TLS密钥时，对应位置导入证书及私钥文件即可。

解答 方案1： 建议您将集群中GPU节点的不可调度的污点去掉，以便GPU插件驱动能够正常安装，同时您需要安装高版本的GPU驱动。 如果您的集群中有非GPU的容器，可以通过亲和、反亲和策略将这个容器不调度到GPU节点上。 方案2： 建议您安装高版本的GPU驱动，通过kubectl更新GPU插件的配置，增加配置如下： tolerations：- operator: "Exists" 增加该配置后，可以使GPU插件驱动能够正常安装到打了污点的GPU节点上。

如何设置容器内的DNS策略？ CCE支持通过dnsPolicy标记每个Pod配置不同的DNS策略： None：表示空的DNS设置，这种方式一般用于想要自定义DNS配置的场景，而且，往往需要和dnsConfig配合一起使用达到自定义DNS的目的。 Default：从运行所在的节点继承名称解析配置。即容器的域名解析文件使用kubelet的“--resolv-conf”参数指向的域名解析文件（CCE集群在该配置下对接云上DNS）。 ClusterFirst：这种方式表示Pod内的DNS使用集群中配置的DNS服务，简单来说，就是使用Kubernetes中kubedns或coredns服务进行域名解析。如果解析不成功，才会使用宿主机的DNS配置进行解析。 如果未明确指定dnsPolicy，则默认使用“ClusterFirst”： 如果将dnsPolicy设置为“Default”，则名称解析配置将从运行pod的工作节点继承。 如果将dnsPolicy设置为“ClusterFirst”，则DNS查询将发送到kube-dns服务。 对于以配置的集群域后缀为根的域的查询将由kube-dns服务应答。所有其他查询（例如，www.kubernetes.io）将被转发到从节点继承的上游名称服务器。在此功能之前，通常通过使用自定义解析程序替换上游DNS来引入存根域。但是，这导致自定义解析程序本身成为DNS解析的关键路径，其中可伸缩性和可用性问题可能导致集群丢失DNS功能。此特性允许用户在不接管整个解析路径的情况下引入自定义解析。 如果某个工作负载不需要使用集群内的coredns，可以使用kubectl命令或API将此策略设置为dnsPolicy: Default。 父主题： 域名DNS

CCE集群节点中安装kubelet的端口主要有哪些？ CCE集群节点中安装kubelet的端口主要有如下几个： 10250 –port：kubelet服务监听的端口，api会检测他是否存活。 10248 –healthz-port：健康检查服务的端口。 10255 –read-only-port：只读端口，可以不用验证和授权机制，直接访问。 4194 –cadvisor-port：当前节点cadvisor运行的端口。 父主题： 节点运行

解决方案 登录节点。 重新创建PV和VG，但是创建时报错： root@host1:~# pvcreate /dev/vdbDevice /dev/vdb excluded by a filter 这是由于添加的磁盘是在另一个虚拟机中新建的，已经存在了分区表，当前虚拟机并不能识别磁盘的分区表，运行parted命令重做分区表，中途需要输入三次命令。 root@host1:~# parted /dev/vdbGNU Parted 3.2Using /dev/vdbWelcome to GNU Parted! Type 'help' to view a list of commands.(parted) mklabel msdosWarning: The existing disk label on /dev/vdb will be destroyed and all data on this disk will be lost. Do you want to continue?Yes/No? yes(parted) quitInformation: You may need to update /etc/fstab. 再次运行pvcreate，当询问是否擦除dos签名时，输入y，就可以将磁盘创建为PV。 root@host1:~# pvcreate /dev/vdbWARNING: dos signature detected on /dev/vdb at offset 510. Wipe it? [y/n]: yWiping dos signature on /dev/vdb.Physical volume "/dev/vdb" successfully created 创建VG。 判断该节点的docker盘，如果是/dev/vdb和/dev/vdc两个盘，则执行下面的命令： root@host1:~# vgcreate vgpaas /dev/vdb /dev/vdc 如果只有/dev/vdb盘，则执行下面的命令： root@host1:~# vgcreate vgpaas /dev/vdb 创建完成后，重置节点即可恢复。

基本介绍 表1 CCE和CCI基本介绍 云容器引擎CCE 云容器实例CCI 云容器引擎（Cloud Container Engine，简称CCE）提供高度可扩展的、高性能的企业级Kubernetes集群，支持运行Docker容器，提供了Kubernetes集群管理、容器应用全生命周期管理、应用服务网格、Helm应用模板、插件管理、应用调度、监控与运维等容器全栈能力，为您提供一站式容器平台服务。借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序。 详细介绍请查看什么是云容器引擎。 云容器实例（Cloud Container Instance， CCI）服务提供Serverless Container（无服务器容器）引擎，让您无需创建和管理服务器集群即可直接运行容器。通过CCI您只需要管理运行在Kubernetes上的容器化业务，无需管理集群和服务器即可在CCI上快速创建和运行容器负载，使容器应用零运维，使企业聚焦业务核心，为企业提供了Serverless化全新一代的体验和选择。 而Serverless是一种架构理念，是指不用创建和管理服务器、不用担心服务器的运行状态（服务器是否在工作等），只需动态申请应用需要的资源，把服务器留给专门的维护人员管理和维护，进而专注于应用开发，提升应用开发效率、节约企业IT成本。传统上使用Kubernetes运行容器，首先需要创建运行容器的Kubernetes服务器集群，然后再创建容器负载。 详细介绍请查看什么是云容器实例。

创建方式 表2 创建方式不同 云容器引擎CCE 云容器实例CCI CCE是基于Kubernetes的托管式容器管理服务，可以提供原生Kubernetes体验，可以一键创建原生Kubernetes集群，与社区能力基本一致。 使用CCE，您需要创建集群和节点，简单、低成本、高可用，无需管理Master节点。 CCI提供 Serverless Container引擎，在华为云上部署容器时，您不需要购买和管理E CS ，可以直接在华为云上运行容器和Pod，为您省去底层ECS的运维和管理工作。 使用CCI，您无需创建集群，无需创建和管理Master节点及Work节点，可直接启动应用程序。

CCE与CCI两者的配合 通过安装Virtual-Kubelet插件，可以在在短时高负载场景时，将部署在CCE上的无状态工作负载（Deployment）、有状态工作负载（StatefulSet）、普通任务（Job）三种资源类型的容器实例（Pod），弹性创建到华为云云容器实例CCI服务上，以减少集群扩容带来的消耗。 具体功能如下： 支持容器实例实现秒级弹性伸缩：在集群资源不足时，无需新增节点，virtual-kubelet插件将自动为您在云容器实例CCI侧创建容器实例，减少运维成本。 无缝对接华为云 容器镜像服务 SWR，支持使用公用镜像和私有镜像。 支持CCI容器实例的事件同步、监控、日志、exec、查看状态等操作。 支持查看虚拟弹性节点的节点容量信息。 支持CCE和CCI两侧实例的service网络互通。 详情请参见华为云 CCE弹性伸缩 至CCI。

问题建议 方案一：发布服务使用域名发现，需要提前预制好主机名和命名空间，服务发现使用域名的方式，注册的服务的域名为：服务名.命名空间.svc.cluster.local 。这种使用有限制，注册中心部署必须容器化部署。 方案二：容器部署使用主机网络部署，然后亲和到集群的某一个节点，这样可以明确知道容器的服务地址（就是节点的地址），注册的地址为：服务所在节点IP，这种方案可以满足注册中心利用VM部署，缺陷是使用主机网络效率没有容器网络高。

如何让多个Pod均匀部署到各个节点上？ Kubernetes中kube-scheduler组件负责Pod的调度，对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的节点去运行这个 Pod。kube-scheduler 给一个 Pod 做调度选择包含过滤和打分两个步骤。过滤阶段会将所有满足 Pod 调度需求的节点选出来，在打分阶段 kube-scheduler 会给每一个可调度节点进行优先级打分，最后kube-scheduler 会将 Pod 调度到得分最高的节点上，如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。 打分优先级中节点调度均衡（BalancedResourceAllocation）只是其中一项，还有其他打分项会导致分布不均匀。详细的调度说明请参见Kubernetes 调度器和调度策略。 想要让多个Pod尽可能的均匀分布在各个节点上，可以考虑使用工作负载反亲和特性，让Pod之间尽量“互斥”，这样就能尽量均匀的分布在各节点上。 示例如下： kind: DeploymentapiVersion: apps/v1metadata: name: nginx namespace: defaultspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: container-0 image: nginx:alpine resources: limits: cpu: 250m memory: 512Mi requests: cpu: 250m memory: 512Mi affinity: podAntiAffinity: # 工作负载反亲和 preferredDuringSchedulingIgnoredDuringExecution: # 尽量满足如下条件 - podAffinityTerm: labelSelector: # 选择Pod的标签，与工作负载本身反亲和 matchExpressions: - key: app operator: In values: - nginx namespaces: - default topologyKey: kubernetes.io/hostname # 在节点上起作用 imagePullSecrets: - name: default-secret 父主题： 调度策略

Headless Service和普通Service的区别 普通Service： 一个Service可能对应多个EndPoint（Pod），client访问的是Cluster IP，通过iptables或IPVS规则转到Real Server，从而达到负载均衡的效果。例如：Service有2个EndPoint，但是DNS查询时只会返回Service的地址，具体client访问的是哪个Real Server，是由iptables或IPVS规则来决定的，客户端无法自行选择访问指定的EndPoint。 Headless Service： 访问Headless Service时，DNS查询会如实的返回每个真实的EndPoint（Pod的IP地址）。对应到每一个EndPoints，即每一个Pod，都会有对应的DNS域名；这样Pod之间就可以互相访问，达到实例间发现和访问的效果。

排查项二：节点IP+节点端口 只有发布为节点访问（NodePort）或负载均衡（LoadBalancer ）的服务才能通过节点IP+节点端口进行访问。 节点访问（NodePort）类型： 节点的访问端口就是节点对外发布的端口。 负载均衡（LoadBalancer ）类型： 负载均衡的节点端口通过“编辑YAML”可以查看。 如下图所示： nodePort: 30637为节点对外暴露的端口。targetPort: 80为Pod对外暴露的端口。port: 123为服务对外暴露的端口，负载均衡类型的服务同时使用该端口配置ELB的监听器。 找到节点端口（nodePort）后，使用容器所在节点的IP地址+端口进行访问，并查看结果是否符合预期。 常见问题： 节点的入方向对业务端口未放通。 节点配置了自定义路由，并且配置错误。 pod的label与service的label不匹配（kubectl或API创建）。

排查项三：负载均衡IP+端口 如果使用负载均衡IP+端口不能访问，但节点IP+端口可以访问。 请排查： 相关端口或URL的后端服务器组是否符合预期。 节点上的安全组是否对ELB暴露了相关的协议或端口。 四层ELB的健康检查是否开启（未开启的话，请开启）。 七层ELB的访问方式中使用的证书是否过期。 常见问题： 发布四层ELB时，如果客户在界面未开启健康检查，ELB可能会将流量转发到异常的节点。 UDP协议的访问，需要放通节点的ICMP协议。 pod的label与service的label不匹配（kubectl或API创建）。

解决方法 如果想要解决这个问题，可以在定时任务的CronJob中配置参数：startingDeadlineSeconds。该参数只能使用kubectl命令，或者通过API接口进行创建或修改。 YAML示例如下： apiVersion: batch/v1kind: CronJobmetadata: name: hellospec: startingDeadlineSeconds: 200 schedule: "* * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox:1.28 imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; echo Hello restartPolicy: OnFailure 如果重新创建CronJob，也可以临时规避这个限制。

排查项一：容器+容器端口 在CCE控制台界面或者使用kubectl命令查找pod的IP，然后登录到集群内的节点或容器中，使用curl命令等方法手动调用接口，查看结果是否符合预期。 如果容器IP+端口不能访问，建议登录到业务容器内使用“127.0.0.1+端口”进行排查。 常见问题： 容器端口配置错误（容器内未监听访问端口）。 URL不存在（容器内无相关路径）。 服务异常（容器内的业务BUG）。 检查集群网络内核组件是否异常（容器隧道网络模型：openswitch内核组件；VPC网络模型：ipvlan内核组件）。