用户集群节点驱散时，会上报两条操作日志 进入节点管理界面，点击节点驱散 驱散成功，但是上报两条操作日志 驱散节点时，会创建go-workflows任务，创建go-workflows时打印了一条，go-workflow里又打印了一条 低版本无需解决，没有实际影响 SKE2.1 解决，改成只打印一条操作日志 节点驱散 否 无实际影响，仅显示问题 NA    

由于NFS自动协商块大小，会导致NFS的读写块大小会尽量往上取（NFS存储内存/4G）* 1024K，最大为1M 如果用户是业务场景为小块频繁并发写场景，可以通过修改挂载参数 rsize，wsize， 来实现小块频繁写的高性能场景 当前界面上未提供挂载参数自定义，用户如果需要修改NFS存储的挂载块大小需要自行通过yaml创建 无 无 无 rsize和wsize的最大值为 1048576 （1M）， 用户可根据自己写入文件的大小酌情修改，SC以及PV参考下方配置 SC的yaml示例 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: ske-com/alias: "" name: rwsize-sc mountOptions: - rsize=4096 - wsize=4096 parameters: csi.ske.com/type: std-nfs nfs.csi.ske.com/server: 10.131.xxx.143 nfs.csi.ske.com/share: /home/data provisioner: nfs.csi.ske.com reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer PV 的yaml示例 apiVersion: v1 kind: PersistentVolume metadata: name: rwsize-static-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Delete mountOptions: - rsize=4096 - wsize=4096 csi: driver: nfs.csi.ske.com volumeHandle: nfs-server.default.svc.cluster.local/share## volumeAttributes: csi.ske.com/type: std-nfs nfs.csi.ske.com/server: 10.131.xxx.143 nfs.csi.ske.com/share: /home/data nfs.csi.ske.com/subdir: "123" 影响NFS的存储写速率，以及写次数，通常大块适合场景为大文件写入，小块适合场景为小文件高频写入 是 无      

创建集群时资源池下拉列最多显示8个，超出的无法选中。 导致期望找某个资源池发现找不到。 NA 前端组件问题，SKE2.0修复了 浏览器F12 -> 选中elements -> 使用旁边那个按钮 -> 界面鼠标点击一下浏览器要选择的元素(这里我们选择下拉框的一行) 找到对应元素后 xxxxxxx，右键删除，Delete Element， 对应删除一行 一直删除，直到找到你需要选择的列表项为止 界面删除元素不对服务造成影响 是 NA NA    

节点部署失败，节点上containerd未启动，且containerd状态为disabled（重启不自启动）。 查看/sf/log/today/ske-vm-disk-handler.sh.log日志发现一直在报分区已挂载，格式化失败的错误。 格式化失败，无法重入执行后续流程。 PS：可能today的日志不对应当天日期，因为日志软链切换是由nglogman处理的，而containerd未启动会导致nglogman等组件未启动进行日志轮转和软链切换。 当出现分区已挂载且格式化失败的错误，则可以检查/boot/flag_init_internal_data_disk_success标志是否存在。 若完成磁盘初始化的标志不存在，则检查，/sf/cfg/ske-vm-disk-handler/ing/create-vdb-partition-table-succeed存在，而/sf/cfg/ske-vm-disk-handler/ing/create-vdb1-succeed不存在，那么可能就是重入失败了。 部署过程中发生了重启，导致ske-vm-disk过程没有执行完全，虽然执行完了磁盘分区、格式化和挂载，但是没有启动containerd，也没有设置containerd为enable，所以后续再重启后，containerd没有重启，也没有进行后续初始化了。 再次启动后，因为当前没有/sf/cfg/ske-vm-disk-handler/ing/create-vdb1-succeed标志，所以重新又执行了，然后又因为已经挂载了，所以格式化错误，也无法执行到下面去重新启动containerd。 由于节点未初始化完成，则按部署失败处置，缩容节点，并重新创建即可快速解决该问题。缩容未部署成功的节点不会影响现有集群运行。 无 是 1.1中已处理，1.0和2.0未处理。 部署失败可能对应很多根因，当出现/sf/log/today/ske-vm-disk-handler.sh.log日志发现一直在报分区已挂载，格式化失败的错误时，才可定位到该问题。 http://docs.sangfor.org/pages/viewpage.action?pageId=386150116      

coredns自定义域名解析hosts NA NA NA kubectl edit configmap coredns -n kube-system 添加hosts{}里面配置对应的域名解析 请配置fallthrough，否则会造成非定制Hosts域名解析失败 apiVersion: v1 data: Corefile: | .:53 { errors health { lameduck 5s } ready   hosts { 127.0.0.1 www.example.com fallthrough }   kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 loop reload loadbalance }   NA NA NA NA      

部署k8s集群失败：控制节点未就绪 部署失败 控制面板状态：控制节点未就绪 SKE的用户集群有个网络要求，需要能访问到SKE的内部通信口。 让客户提供两个截图 【SKE界面】部署失败的集群的【集群网路】-【基本配置】 【SCP界面】-【公共服务网路】-【容器服务】 通过这个图可以看到，192.168.80.x的k8s节点是不能访问到【SKE内部通信口】10.1.1.10，所以会部署失败 解决方案： 删除该集群，使用【隔离模式部署】 管理网：用10.1.1.x 业务为：192.168.80.x 大概率网络不通，或者vlan不通 参考上面有效排查步骤，让客户提供两个截图，分析是否网络不通，是的话，建议使用【隔离模式部署】即可，配置就是管理网跟内部通信口一个网段，业务口用客户原来期望的网段 如果满足了网络互通，仍然部署失败，这时候考虑是其他问题，需要登录部署失败的节点的后台，账户root密码k8sadmin, 尝试ping一下内部通信口，并且测试arping，排查下是否存在网络问题。可能是存在ip冲突，或者vlan端口，或者本身网络隔离存在问题。 这里如何排查网络，先找到内部通信口在哪，实际的内部通信口，是挂载在【容器服务】直连的路由器上。保证k8s节点管理口连接的设备，能访问到这个路由器，随后创建集群能ping到，就会开通成功的。 NA 否 NA NA      

配置 HPA 阈值为 n，当前 HPA 关联的工作负载使用率已经达到 101% * n，并没有立刻触发扩容 无 kubectl top 命令查看工作负载资源当前使用量 检查：[当前工作负载使用量/HPA中配置的期望使用量（request * 阈值百分比）] 比例是否在 0.9 ~ 1.1 区间，该区间内不会触发扩缩容 kube-controller-manager 计算 HPA 时，存在一个默认的容忍度（不能为 0），防止系统质保抖动造成频繁的扩缩容。 Kubernetes 官方文档的说明如下： 从最基本的角度来看，Pod 水平自动扩缩控制器根据当前指标和期望指标来计算扩缩比例。 期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)] 例如，如果当前指标值为 200m，而期望值为 100m，则副本数将加倍， 因为 200.0 / 100.0 == 2.0 如果当前值为 50m，则副本数将减半， 因为 50.0 / 100.0 == 0.5。如果比率足够接近 1.0（在全局可配置的容差范围内，默认为 0.1）， 则控制平面会跳过扩缩操作。 容忍度范围内，不会立刻触发扩缩容属期望效果，是原生机制，无需担心。 不涉及 不涉及 HPA中的容忍度概念能缓解指标波动带来的系统震荡问题，同时容忍度的存在也需要运维人员关注到。 NA      

当出现一个集群部分节点部署正常，部分节点网络异常时，且根据经验排查发现是子网不通时，可以根据该文档提供的思路进行排查。可能为SKE子网掩码和Kubernetes集群子网掩码不同导致的。 该场景现象如下：如果当前开通SKE时设置了内部通信口的子网掩码为255.255.255.0，但是平时使用一直以为子网掩码为255.255.240.0，使用经典网络设置的IP范围的子网掩码或使用VPC网络配置的弹性IP池的范围的子网掩码是255.255.240.0。但是由于是和SKE内部通信口子网掩码255.255.255.0同网段的IP开始的，所以一开始不会有什么问题。而当IP超出网段后，则部署的节点会出现网络连通性故障的问题。但是由于之前节点都很正常，且无法很轻松得知SKE内部通信口的子网掩码是255.255.255.0，较难排查到是该问题导致的故障。 集群部分节点部署失败。 该问题可能是因为SKE内部通信口子网掩码和Kubernetes集群子网掩码不一致导致的。 查看SKE子网掩码的方式： 方式1：从SKE的configmap relative-info中获取。 方式2：从网络规划的SKE内部通信口连接的边界路由器的网口处获取。 检查SKE和Kubernetes集群IP配置范围是否在同一网段范围内，若不在，则会导致网络不通。 比如这里的211.188.55.35和Kubernetes的211.188.55.37是同一子网的，互相能访问。但是211.188.56.38和SKE的内部通信口的211.188.55.35就跨网段了。 SKE子网范围小于Kubernetes集群IP的子网范围。可能集群一开始部署的节点是正常的，超出范围则会因网络问题导致部署失败。 修改IP范围与SKE同网段。或联系技术支持，修改SKE边界路由器的子网掩码。 Kubernetes集群部署过程。 是，该问题是由于网络规划不合理导致的。 该问题可能发生概率较小，但是也有配置错误的可能性。 当部署节点多的大集群，可能会触发该问题，该场景遇到部分节点因网络问题部署失败，可以考虑往这一方向进行排查。 http://docs.sangfor.org/pages/viewpage.action?pageId=383451312      

大多数情况下，直接在SKE上部署k8s集群，可能出现部署失败的问题。 这里讲一下，如何快速成功开通用户集群 NA NA NA 【关键在于和SKE内部通信口打通】(后文全部ip均来自内网测试环境，跟客户无关) 一、确定SKE内部通信口的IP和连接的设备 比如这里我就是13.199.27.8 二、分析自己开通集群的配置，是否能访问到此路由器即可，大多数人开通失败的原因就是网络实际到不了内部通信口（13.199.27.8） 三、下面提供几种开通成功的方案（推荐隔离模式，多一个网卡，用于业务访问，也可以自定义自己期望的网段） 使用【复用模式】 ip范围用13.199.27.x 连接到物理出口1 使用【隔离模式】 管理口13.199.27.x 连接到物理出口1；业务口按自己的预期来，连接设备也按自己预期来。 NA NA NA NA      

创建集群失败，worker节点部署失败，cilium容器启动异常 界面部署失败 + cilium组件没起来 部署失败的情况下，可以直接使用密码k8sadmin进入节点查看情况。部署成功后密码才会随机 去节点使用crictl ps查看情况，并且通过crictl logs -f查看cilium失败原因 从原因来看是cilium里面请求apiserver的地址失败，这个地址是service网段的第一个，然后会通过iptables转发给VIP所在节点的节点IP上去 通过iptables -t nat -S | grep -w ${cilium里面报错的IP} （下图假设前面报错的是10.96.0.1） 找到相关的链，再grep这个找到实际映射出去的IP地址（如下图） 查看下这ip，发现是master节点的业务口ip，master节点是部署成功的，应该要提供服务 通过curl https://${master-业务口IP}:6443 -k 发现通不了，curl https://${VIP}:6443 ip是能访问到该服务 尝试arping ${master-业务口IP}发现mac对不上，那大概率是ip冲突了，尝试去环境里面找是否有路由、主机、弹性ip等地方配置了此ip 最后客户视察环境，确实发现了两个ip已经被使用了，前就存在客户用了弹性ip挂载路由器，然后忘记了，后续把已经用了的弹性ip给了新的主机，导致了非预期的worker节点部署失败 ip冲突，导致节点cilium访问apiserver，通过iptables DNAT映射出去的地址实际没走到master节点，访问apiserver服务被拒绝或者超时。 需要去测试下apiserver服务是否真的在运行，一般通过节点的/etc/hosts是通过VIP去访问的，如果OK，而cilium出问题 然后得看得看能否ping通，能否发大包。 然后再看是否arping得到多个mac地址，或者地址对不上。 参考上面排查网络问题 NA NA NA NA        

用户集群部署失败 ske告警ske-agent健康探测失败 用户集群节点可以直接通过 root + k8sadmin登录 还没有到重置密码的步骤 节点cat /etc/hosts 没有ske的域名配置 确定k8s节点已经生成了，但密码还是默认的k8sadmin, 说明初始化流程没走完 进入节点查看/etc/hosts发现没有ske相关的域名，说明初始化阻塞在某个地方，还没下发初始的事件 进入SKE后台查看日志：cat /sf/log/today/cluster-server.log，无相关错误日志 查看api-provider 没相关日志 kubectl edit deployment cluster-api-provicer 编辑-v=5看更多日志 tail 查看发现Check ske agent health failed. 梳理一下SKE管理节点如何探测集群ske-agent健康的，发现是默认通过svc建立云梯 agent-api:26000 --> 用户集群的ske-agent:20411 kubectl get svc -A |grep agent-api 所以目前来看大概率是用户集群的ske-agent服务没起来。可以通过下面命令查看相关服务 crictl ps | grep ske-agent systemctl status ske-agent 通过systemctl status ske-agent发现服务在运行，但20411端口没有开放服务，发现配置文件不存在，所以没启动到指定的端口上。 问题分析 ske-agent的启动依赖aksk文件的初始化 akske的初始化依ske域名的下发 ske域名的下发需要ske-agent-init服务健康 并且由ske测hciprovicer的协调器去跟xaas-api获取网络信息后去调用ske-agent-init的设置域名的接口 现在发现hcimachine里面已经有了condition：SKELinkConfigReady认为已经就绪了，但实际没下发 怀疑是请求下发的了，但失败了，最后定位到是数据包分发不下去 网络通，但数据包发送失败 联系HCI同事调整数据包分片问题，例如修改MTU之类的。 NA NA NA #22 (closed)      

用户创建集群的时候报错，提示集群占用配额失败 用户创建集群的时候报错，提示集群占用配额失败 私有云环境： 登录到私有云管理控制台。 导航到权限管理模块。 选择 admin 用户。 配置SCP策略，确保 vCPU 资源的授权。 托管云环境： 登录到托管云的SCC。 导航到租户管理模块。 选择需要授权的租户节点。 配置相应的授权策略，确保 vCPU 资源的授权 未正确配置用户配额，导致集群创建失败。 私有云环境： 登录SCP后台。 admin账户 → 系统管理→ 平台授权 里面查看容器服务是否授权了 admin账户 → 系统管理→ 服务授权 里面查看容器服务是否有分配vCPU 协管员或者租户需要查看 用户与访问管理 里面是否给了资源配额 托管云环境： 登录到托管云的SCC。 系统设置里面选择对应的租户，给租户对应的节点授权 NA NA 私有云和托管云都要考虑好授权数量 NA    

需要能从前端强制删除PV及PVC 界面上一直删除PV和PVC都还是没有反应 确保也没有POD在使用，如果有重试强制清理pod即可。 如果确定是要不管其他的情况，就是要删除PV和PVC可以参考后文 PV及PVC存在finalizers字段，会保护里面的数据 直接通过界面或者kubectl编辑，将finalizers字段删除后，等待一会即可清理（如果没有再次点击删除试一下）  NA NA NA NA    

SKE1.0 创建的nodeport service类型是随机分配的物理端口 正常应该需要指定端口 NA NA NA 先通过SKE-UI创建一个nodeport类型的service yaml内找到nodeport字段修改为期望的nodeport NA 是，此问题2.0已修复 NA NA    

误删除的PVC处于termaning时，如何避免delete策略的PV数据被清空 NA 直接删除PVC不会直接删除PVC，会等待使用的POD结束。此时POD还在运行，PVC就处于termaning状态。 一定POD被清理了，PVC就结束状态， PV配置了delete策略，PVC一旦删除，数据也就清理了。 所以这里要做两个事情，一个是更改PV的策略，让它不删除 一个是让PV重新绑定新的PVC NA 通过kubectl或者界面直接编辑yaml，把pv的策略改成Retain 保存pvc的yaml，使用kubectl get pvc xxx > temp.yaml或者直接界面复制yaml后保存 强制清理删除kubectl patch pvc xxxxx-pvc -n -p '{"metadata":{"finalizers":null}}' 或者使用SKE界面编辑yaml，手动把finalizers字段改成null。 把使用PVC的业务副本变成0，等pvc自动删除。 此时PV处于不可用状态，需要让它重新可用。kubectl或者界面UI编辑yaml把pv里面的CaimsRef字段全部删除，此时PV状态变为可用。 重新apply前面保留的PVC配置文件temp.yaml，pv重新绑定pvc 再把工作负载副本变成1，此时业务恢复，PV数据都保留了 NA NA 有能力的可以直接开源平台找方案，这个流程应该是大差不差的。 NA    

k8s集群配置的cpu管理策略为“默认策略”，拓扑管理策略配置为“默认策略”以外的任一种。 通过页面的“创建YAML”入口或者下载kubeconfig使用kubectl， 创建配置了numa拓扑策略的vcjob或者pod，pod会调度失败。 无 查看 volcano-scheduler 的日志， kubectl logs -f -l app=volcano-scheduler -n ske-system  ，有如下红框的内容 问题原因：节点的 CPU管理策略为 none ，而 拓扑管理策略不为 none ，pod 的拓扑管理策略不为 none。 volcano调度pod时，找相同拓扑管理策略的节点时，会先判断节点的 CPU管理策略是否为 static ，不为 static 的也认为是无法调度到此节点。 总结下不能调度的情况： “pod 为 PodQOSGuaranteed” 且 “pod 有配拓扑策略” 且 （ “node cpu策略不为static” 或者 “node 拓扑策略和 pod 不一样”） 方案一：去掉vcjob/pod配置的numa拓扑策略。 方案二：修改 CPU 管理策略为 static，或者，修改拓扑管理策略为“默认策略” 方案一：影响编辑的这个vcjob/pod 方案二：影响编辑的这个集群   否 - 资源管理策略一般不会这样配置（cpu管理策略为默认、拓扑管理策略不为默认）,如果有人这样配置了，问下为什么这样配的原因。 NA      

删除软件包过程中若出现镜像删除失败等前置清理的问题，会残留该版本软件包的configmap，导致下一次上传同版本软件包失败。 前端提示已存在相同版本软件包，但是UI界面上无法看到该版本软件包，无法继续删除。 上传软件包时会检查是否包含label的version相同的configmap，只允许存在一个，作为同版本软件包不能冲突的依据。 查看sys-api日志： 检查configmap的num个数错误，对应代码： 导致删除软件包后，残留configmap的原因：删除软件包的时候会先删除相关的镜像，每一步骤都会重试五次，如果重试失败，则直接返回报错，然后不会执行之后的逻辑。 有镜像删除失败十次（coredns:v1.9.3）删除失败五次（coredns:v1.8.6），有的只删除失败一次（kube-proxy:v1.25.16）：   外层调用的err报了0x00000000000D0CFC的为三次，对应了内层函数有三个镜像失败过五次，coredns:v1.9.3失败两次，coredns:v1.8.6失败一次。  删除镜像有一个镜像失败五次就会导致err != nil，然后直接return，没有执行后面的删除configmap的逻辑。 此外，整理了以下情况可能导致后续流程未走完而残留configmap：  获取configmap失败 创建删除ulog失败 准备删除configmap失败 获取软件包信息失败 删除镜像失败 残留同版本软件包的configmap。 后台删除指定版本软件包： 例如：当前UI上删除了1.24.17版本的软件包，前台未显示，但是后台残留configmap，可通过命令查看是否存在该问题，然后删除该configmap。 步骤： 查看K8s软件包版本，如软件包命名为【K8s_Components_Bundle_v1.24.17_X86_for_SKE1.1.0(20240902030300)】，则K8s软件包版本为k8s-package-version=v1.24.17。 查看SKE版本，可从【SCP/容器服务/设置/容器服务升级】处看到当前容器服务SKE的版本，如显示【当前版本：SKE1.1.0-2024-09-03_02:44:02】，则SKE版本为ske-version=v1.1.0。 获取sangfor.com/version，格式为：${k8s-package-version}-ske.${ske-version}，即sangfor.com/version=v1.24.17-ske.v1.1.0。 SKE后台查看与上传失败软件包同版本label的configmap： 1 2 3 4 $ kubectl get configmap -l sangfor.com/type=K8S,sangfor.com/version=v1.24.17-ske.v1.1.0 -n default   NAME                                               DATA   AGE k8s-package-5fbcbbf2-8edb-493b-a0d4-17d62a8b6d2f   1      19h 删除残留的configmap： 1 2 $ kubectl delete configmap -l sangfor.com/type=K8S,sangfor.com/version=v1.24.17-ske.v1.1.0 -n default configmap "k8s-package-5fbcbbf2-8edb-493b-a0d4-17d62a8b6d2f" deleted 重新从UI界面上传K8s软件包。 删除遗留K8s软件包的configmap 是临时解决方案，完整解决方案在SKE2.0.0已修复。   Q：删除失败后为什么没有在UI上显示删除失败？能否UI上重试删除？ A：因为SKE1.0.0和SKE1.1.0的软件包管理状态没有删除失败状态，在SKE2.0.0进行增加[fix]新增删除失败状态 (!932) · 合并请求 · VC / 容器业务 / GatewayServices · GitLab (sangfor.org)。 触发该问题是一个概率极小的情况，只有当删除时某一步骤出现重试5次失败，才会导致最后残留configmap，继而导致下次上传失败。 上传K8s软件包是使用频率较低的功能，由于SKE2.0.0已修复该问题，支持UI界面重试删除K8s软件包，故SKE1.0.0和SKE1.1.0采用手动在后台恢复的方式解决该问题，解决方式也较为简单。 2024.9.3-删除K8s软件包后重新上传显示重复 - VT - Sangfor文档管理    

界面仅支持创建单主机读写的PVC 无 无 设计原因，忽略了客户常用场景 不使用ui，直接通过编写yaml指定readWriteMany创建 无 是 无 无          

处于安全考虑，界面只支持创建https协议的镜像仓库凭证，但有些客户有需求使用http协议的 无 无 设计问题，未适配客户常用场景 先创建https的，然后点开这个secret，点击编辑yaml-》复制 .dockerconfigjson 的内容进行 base64 解码，将里面https改成http填充回去 -》 保存即可 可以参考下面方法echo "eyJhdXRocyI6eyJodHRwczovL3Rlc3QuY29tIjp7InVzZXJuYW1lIjoicm9vdCIsInBhc3N3b3JkIjoidGVzdCJ9fX0=" | base64 --decode | sed 's/https/http/g' | base64 | tr -d '\n' 得到eyJhdXRocyI6eyJodHRwOi8vdGVzdC5jb20iOnsidXNlcm5hbWUiOiJyb290IiwicGFzc3dvcmQiOiJ0ZXN0In19fQ== 填回配置 无 是 通过yaml修改后，界面去看这个secret可能现象是https:// http://xxxx.com 是正常的，不用管，后续都通过yaml修改该secret即可。 无        

客户配置好kubectl后，按照SKE界面提示使用kubeconfig报错了。 情况1：报错内容为 no such hosts 情况2：报错内容为unable to conect to the server x509： certificate is valid for xxx notske-demo-wonl.ske-usercluster 情况1：字面意思，缺少域名解析，本地解析域名即可 情况2：说明apiserver不支持该域名，正常SKE的apiserver已经对*.ske-usercluster 进行了放通，这里报错说明可能环境异常了 去用户集群master后台查看ske支持哪些域名。cd /etc/kubernetes/pki &&  openssl x509 -in apiserver.crt -noout -text|grep -A  2 'Alternative' 然后使用一个支持的域名就行，比如kubernetes.default 情况1：kubeconfig界面使用流程缺少引导 情况2：升级或者其他情况异常场景 情况1：表示没有做域名解析，需要解析该域名到对应的集群VIP 配置kubeconfig里面的域名xxxxxxxx.ske-usercluster解析到集群VIP  集群VIP需要前往 集群管理→ 选择对应的集群左上角集群状态，可以看到集群VIP（如果没有集群权限，请联系有集群权限的人给一下集群VIP) kubeconfig内部的server域名可以从文件里面拿 配置完后ping一下xxxxxxxx.ske-usercluster能通即可，kubectl就会通过它去连接集群的apiserver，然后kubectl就可用了   情况2：表示证书里面的域名不被apiserver支持 kubernetes.default是支持的域名之一，可以手动改成用这个 证书里面的域名xxxxxxxx.ske-usercluster 改成kubernetes.default，本地解析kubernetes.default 到集群VIP或者master节点ip即可。 无 是   原理就是保证kubeconfig里面域名能准确解析到指向的地址是集群vip或者master节点即可。 无