华为云用户手册

约束与限制 “节点访问 ( NodePort )”默认为VPC内网访问，如果需要使用弹性IP通过公网访问该服务，请提前在集群的节点上绑定弹性IP。 创建service后，如果服务亲和从集群级别切换为节点级别，连接跟踪表将不会被清理，建议用户创建service后不要修改服务亲和属性，如需修改请重新创建service。 通过控制台创建的NodePort类型Service，Service端口与设置的容器端口一致。 CCE Turbo集群仅支持集群级别服务亲和。

externalTrafficPolicy（服务亲和） NodePort类型的Service接收请求时先从访问到节点，然后转到Service，再由Service选择一个Pod转发到该Pod，选择的Pod不一定在接收请求的节点上。默认情况下，从任意节点IP+服务端口都能访问到后端工作负载，当Pod不在接收请求的节点上时，请求会在跳转到Pod所在的节点，带来一定性能损失。 Service有一个配置参数externalTrafficPolicy，如下所示。 apiVersion: v1kind: Servicemetadata: name: nginx-nodeportspec: externalTrafficPolicy: local ports: - name: service nodePort: 30000 port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: NodePort 当externalTrafficPolicy取值为local时，通过节点IP:服务端口的请求只会转发给本节点上的Pod，如果节点没有Pod的话请求会挂起。 externalTrafficPolicy还有一个取值是cluster，也是默认取值，就是前面说的请求会在集群内转发。 在CCE 控制台创建NodePort类型Service时也可以配置该参数。 总结externalTrafficPolicy两个取值。 cluster（集群级别）：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 local（节点级别）：只有通过负载所在节点的IP+访问端口才可以访问此服务关联的负载，服务访问没有因路由跳转导致的性能损失，且可以获取到客户端源IP。

工作负载创建时设置 您可以在创建工作负载时通过控制台设置Service访问方式，本节以nginx为例进行说明。 参考创建无状态负载(Deployment)、创建有状态负载(StatefulSet)或创建守护进程集(DaemonSet)，在“工作负载访问设置”步骤，单击“添加服务”。 访问类型：选择“节点访问 ( NodePort )”。 如果需要使用弹性IP通过公网访问该服务，请提前在集群的节点上绑定弹性IP。 Service名称：自定义服务名称，可与工作负载名称保持一致。 服务亲和：详情请参见externalTrafficPolicy（服务亲和）。 集群级别：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 节点级别：只有通过负载所在节点的IP+访问端口才可以访问此服务关联的负载，服务访问没有因路由跳转导致的性能损失，且可以获取到客户端源IP。 IPv6：默认不开启，开启后服务的集群内IP地址（ClusterIP）变为IPv6地址，具体请参见如何通过CCE搭建IPv4/IPv6双栈集群？。该功能仅在1.15及以上版本的集群创建时开启了IPv6功能才会显示。 端口配置： 协议：请根据业务的协议类型选择。 容器端口：容器镜像中工作负载实际监听的端口，取值范围为1-65535。 访问端口：容器端口映射到节点私有IP上的端口，建议选择“自动生成”。 自动生成：系统会自动分配端口号。 指定端口：指定固定的节点端口，默认取值范围为30000-32767。若指定端口时，请确保同个集群内的端口唯一性。 完成配置后，单击“确定”。 单击“下一步：高级设置”进入高级设置页面，直接单击“创建”。 单击“查看工作负载详情”，在访问方式页签下获取访问地址，例如“192.168.0.160:30358”。

部署命令 rolling-update* rolling-update是一个非常重要的命令，对于已经部署并且正在运行的业务，rolling-update提供了不中断业务的更新方式。rolling-update每次起一个新的pod，等新pod完全起来后删除一个旧的pod，然后再起一个新的pod替换旧的pod，直到替换掉所有的pod。rolling-update需要确保新的版本有不同的name，Version和label，否则会报错 。 kubectl rolling-update poname -f newfilenamekubectl rolling-update poname -image=image:v2 如果在升级过程中，发现有问题可以中途停止update，并回滚到前面版本。 kubectl rolling-update poname -rollback rollout 管理资源的发布。 例如： 查看指定资源的部署状态： kubectl rollout status deployment/deployname 查看指定资源的发布历史： kubectl rollout history deployment/deployname 回滚指定资源，默认回滚至上一个版本： kubectl rollout undo deployment/test-nginx scale scale用于程序在负载加重或缩小时将副本进行扩容或缩小。 kubectl scale deployment deployname --replicas=newnumber autoscale autoscale命令提供了自动根据pod负载对其副本进行扩缩的功能。autoscale命令会给一个rc指定一个副本数的范围，在实际运行中根据pod中运行的程序的负载自动在指定的范围内对pod进行扩容或缩容。 kubectl autoscale deployment deployname --min=minnumber --max=maxnumber

集群管理命令 cordon、drain、uncordon* 有时候会遇到这样一个场景，一个node需要升级，但是在该node上又有许多运行的pod，或者该node已经瘫痪，需要保证功能的完善，则需要使用这组命令，使用步骤如下： 使用cordon命令将一个node标记为不可调度。这意味着新的pod将不会被调度到该node上。 kubectl cordon nodename 备注：CCE中nodename为节点私网IP。 使用drain命令，将运行在该node上运行的pod平滑的搬迁到其他节点上。 kubectl drain nodename --ignore-daemonsets --ignore-emptydir 备注：ignore-emptydir为用户挂载空目录的数据。 对该节点进行一些节点维护的操作，如升级内核、升级Docker等。 节点维护完后，使用uncordon命令解锁该node，使其重新变得可调度。 kubectl uncordon nodename cluster-info 查看在集群中运行的插件： kubectl cluster-info 查看详细信息： kubectl cluster-info dump top* 显示资源（CPU/Memory/Storage）使用。需要Heapster运行。 taint* 修改一个或多个节点上的taint。 certificate* 修改证书资源。

高级命令 replace replace命令用于对已有资源进行更新、替换。当需要更新resource的一些属性的时候，如果修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令。 kubectl replace -f filename 名字不能被更新。 apply* apply命令提供了比patch，edit等更严格的更新resource的方式。通过apply，用户可以将resource的configuration使用source control的方式维护在版本库中。每次有更新时，将配置文件推送到server，然后使用kubectl apply将更新应用到resource。kubernetes会在引用更新前将当前配置文件中的配置同已经应用的配置做比较，并只更新更改的部分，而不会主动更改任何用户未指定的部分。apply命令的使用方式同replace相同，不同的是，apply不会删除原有resource，然后创建新的。apply直接在原有resource的基础上进行更新。同时kubectl apply还会在resource中添加一条注释，标记当前的apply，类似于git操作。 kubectl apply -f patch 如果一个容器已经在运行，这时需要对一些容器属性进行修改，又不想删除容器，或不方便通过replace的方式进行更新。kubernetes还提供了一种在容器运行时，直接对容器进行修改的方式，就是patch命令。 例如已存在一个pod的label为app=nginx1，如果需要在运行过程中，将其修改为app=nginx2。 kubectl patch pod podname -p '{"metadata":{"labels":{"app":"nginx2"}}}' convent* 不同的api版本之间转换配置文件。

使用Kubernetes官方模板包 访问https://artifacthub.io/，获取需要的社区模板包。 登录Linux机器。 上传1中获取到的模板包。 执行如下命令，压缩模板包。 若Linux机器没有安装Helm客户端，则执行如下命令。 tar pzcf {name}-{version}.tgz {name}/ 其中， {name}替换为实际的模板包名。 {version}实际的模板包版本号。 {name}和{version}必须与模板包中Chart.yaml中所写的name和version相同。 若Linux机器已安装Helm客户端，则执行如下命令。 helm package {name}/ 其中，将{name}替换为实际的模板包名。 按照模板包规范的要求设置模板包目录结构和命名模板包。

获取驱动链接-公网地址 登录CCE控制台。 创建节点，在节点规格处选择要创建的GPU节点，选中后下方显示的信息中可以看到节点的GPU显卡型号。 图1 查看显卡型号 登录到https://www.nvidia.com/Download/Find.aspx?lang=cn网站。 如图2所示，在“NVIDIA驱动程序下载”框内选择对应的驱动信息。其中“操作系统”必须选Linux 64-bit。 图2 参数选择 驱动信息确认完毕，单击“搜索”按钮，会跳转到驱动信息展示页面，该页面会显示驱动的版本信息如图3，单击“下载”到下载页面。 图3 驱动信息 获取驱动软件链接方式分两种： 方式一：如图4，在浏览器的链接中找到路径为url=/tesla/396.37/NVIDIA-Linux-x86_64-396.37.run的路径，补齐全路径https://us.download.nvidia.com/tesla/396.37/NVIDIA-Linux-x86_64-396.37.run该方式节点需要绑定EIP 。 方式二：如图4，单击“下载”按钮下载驱动，然后上传到OBS，获取软件的链接，该方式节点不需要绑定EIP。 图4 获取链接

验证插件 插件安装完成后，在GPU节点及调度了GPU资源的容器中执行nvidia-smi命令，验证GPU设备及驱动的可用性。 GPU节点： # 插件版本为2.0.0以下时，执行以下命令：cd /opt/cloud/cce/nvidia/bin && ./nvidia-smi# 插件版本为2.0.0及以上时，驱动安装路径更改，需执行以下命令：cd /usr/local/nvidia/bin && ./nvidia-smi 容器： cd /usr/local/nvidia/bin && ./nvidia-smi 若能正常返回GPU信息，说明设备可用，插件安装成功。

卸载插件 在CCE控制台，单击左侧导航栏的“插件管理”，在“插件实例”页签下，选择对应的集群，单击virtual kubelet下的“卸载”。 在弹出的窗口中，单击“确认”，可卸载该插件。（卸载插件会自动删除CCI侧的所有资源，以确保不会有资源残留造成额外计费） 如果在未卸载virtual-kubelet插件的情况下直接删除集群，CCI侧的资源不会被自动清理，会导致CCI侧资源残留，可能会造成额外计费。因此请确保完成以下任意一操作。 在删除集群前先卸载virtual-kubelet插件。 在直接删除集群后登录CCI控制台删除名为cce-burst-${CLUSTER_ID}的命名空间。 集群休眠时CCI侧正在运行的实例不会自动停止，会持续运行并计费。因此如不需要实例继续运行，请确保在集群休眠前将弹性到CCI的负载实例数缩至0。

约束与限制 gpu-beta插件仅在部分区域可用。 仅支持在v1.11及以上版本的CCE集群中安装本插件，暂不支持鲲鹏集群。 集群中使用GPU节点时必须安装gpu-beta插件。 下载的驱动必须是后缀为“.run”的文件。 仅支持Tesla驱动，不支持GRID驱动。 如果下载链接为公网地址，如nvidia官网地址https://us.download.nvidia.com/tesla/396.37/NVIDIA-Linux-x86_64-396.37.run，各GPU节点均需要绑定EIP。获取驱动链接方法请参考获取驱动链接-公网地址。 若下载链接为OBS上的链接，无需绑定EIP 。获取驱动链接方法请参考获取驱动链接-OBS地址。 请确保Nvidia驱动版本与GPU节点适配。 更改驱动版本后，需要重启节点才能生效。

安装插件 登录CCE控制台，在左侧导航栏中选择“插件管理”。在“插件市场”页签下，单击gpu-beta插件下的“安装插件”。 在安装插件页面，选择安装的集群和插件版本，单击“下一步：规格配置”。 在规格配置页面，配置驱动链接地址。 单击“安装”，安装gpu-beta插件的任务即可提交成功。 待插件安装完成后，单击“返回”，在“插件实例”页签下，选择对应的集群，可查看到运行中的实例，这表明该插件已在当前集群中各GPU节点上安装。

升级插件 登录CCE控制台，在左侧导航栏中选择“插件管理”，在“插件实例”页签下，选择对应的集群，单击“virtual-kubelet”下的“升级”。 如果升级按钮处于冻结状态，则说明当前插件版本是最新的版本，不需要进行升级操作。 升级“virtual-kubelet”插件时，会替换原先节点上的旧版本的“virtual-kubelet”插件，安装最新版本的“virtual-kubelet”插件以实现功能的快速升级。 在基本信息页面选择插件版本，单击“下一步”。 参考安装插件中参数说明配置参数后，单击“升级”即可升级“virtual-kubelet”插件。

资源自动规整 对弹性到CCI的Pod，若其配置的资源规格不满足CCI容器规范，virtual-kubelet会自动尝试将Pod资源向上规整到满足CCI容器规范的范围，以规整后的资源规格创建Pod到CCI。 自动规整规则如下： 将Pod中除了BestEffort类型容器外的每个容器CPU向上调整至0.25核的整数倍， Memory向上调整至大于等于0.2Gi。 将整个Pod的Memory向上调整至1Gi的整数倍。 若Pod Memory/CPU的比值小于2，则将Pod Memory向上调整至大于等于CPU的2倍，且满足是1Gi的整数倍；若Pod Memory/CPU的比值大于8，则将Pod CPU向上调整至大于等于Memory的1/8，且满足是0.25核的整数倍。 若向上调整之后，CPU超过32核或Memory超过256Gi，则矫正失败，拒绝创建请求。 以上对Pod级别资源向上调整造成的增量CPU和Memory，全部添加到Pod中第一个不为BestEffort的容器上。

Virtual Kubelet可分配资源监控影响说明 安装Virtual Kubelet插件后，从监控的角度，相当于引入一个超大节点，此时在CCE集群监控界面上可分配资源使用率会把CCI的资源放在一起计算。如下所示，刚安装Virtual Kubelet插件后，CPU/内存的可分配率剧烈下降。 图3 集群监控 您可以在节点管理界面或AOM中查看具体节点的分配率。 图4 查看节点可分配资源 图5 在AOM中查看节点资源可分配率

约束及限制 仅支持VPC网络模式的CCE集群和CCE Turbo集群（virtual-kubelet 1.2.5版本及以上支持），且仅支持1.21及以下集群。 调度到CCI的实例的存储类型只支持ConfigMap、Secret、emptyDir、SFS、SFS Turbo几种Volume类型，其中emptyDir不支持子路径，且SFS、SFS Turbo类型存储对应的PVC只支持使用CSI类型的StorageClass。 暂不支持守护进程集（DaemonSet）以及HostNetwork网络模式的容器实例（Pod）弹性到CCI。 跨CCE和CCI实例Service网络互通只支持集群内访问（ClusterIP）类型。 跨CCE和CCI实例，在对接LoadBalancer或Ingress时，禁止指定健康检查端口： 1. 在CCE集群下，由于CCI的容器与CCE的容器在ELB注册的后端使用端口不一致，指定健康检查端口会导致部分后端健康检查异常。 2. 跨集群使用Service对接同一个ELB的监听器时，需确认健康检查方式，避免服务访问异常。 集群所在子网不能与10.247.0.0/16重叠，否则会与CCI命名空间下的Service网段冲突，导致无法使用。 使用插件前需要用户在CCI界面对CCI服务进行授信。 安装virtual-kubelet插件后会在CCI服务新建一个名为"cce-burst-"+集群ID的命名空间，该命名空间完全由virtual-kubelet管理，不建议直接在CCI服务使用该命名空间，如需使用CCI服务，请另外新建命名空间。 实例的规格必须满足云容器实例CCI的容器规范。 使用1.2.5以下版本插件时，各容器的Requests须等于Limits（1.2.5及以上版本插件两者可不相等，弹性到CCI时自动将两者设置为一样，若配置了Limits，则以Limits为准，没有配Limits，则以Requests为准）。 Pod中至少有1个容器配置CPU大于0。 经过资源自动规整后，Pod总CPU不得超过32核，内存不得超过256Gi。

安装插件 在CCE控制台，单击左侧导航栏的“插件管理”，在“插件市场”页签下，单击virtual-kubelet插件下的“安装插件”。 在“基本信息”步骤中，选择安装的集群和插件版本，单击“下一步：规格配置”。 在“规格配置”步骤中，勾选“跨服务互通”后的选择框，可实现CCE集群中的Pod与CCI集群中的Pod通过Kubernetes Service互通。 图1 勾选“跨服务互通” 单击“安装”。 待插件安装完成后，单击“返回”，在“插件实例”页签下，选择对应的集群，可查看到运行中的实例，这表明该插件已在当前集群的各节点中安装。

通过工作负载YAML进行DNS配置 您也可以通过YAML的方式创建工作负载，以nginx应用为例，其YAML文件中的DNS配置示例如下： apiVersion: apps/v1kind: Deploymentmetadata: name: nginx namespace: defaultspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: container-1 image: nginx:latest imagePullPolicy: IfNotPresent imagePullSecrets: - name: default-secret dnsPolicy: None dnsConfig: options: - name: ndots value: '5' - name: timeout value: '3' nameservers: - 10.2.3.4 searches: - my.dns.search.suffix dnsPolicy字段说明： dnsPolicy字段是应用设置的DNS策略，默认值为“ClusterFirst”。基于dnsPolicy策略生成的域名解析文件会与dnsConfig设置的DNS参数进行合并，合并规则将在表2中说明，dnsPolicy当前支持四种参数值： 表1 dnsPolicy字段说明 参数 说明 ClusterFirst（默认值） 应用对接CoreDNS（CCE集群的CoreDNS默认级联云上DNS）。这种场景下，容器既能够解析service注册的集群内部域名，也能够解析发布到互联网上的外部域名。由于该配置下，域名解析文件设置了search搜索域列表和ndots: 5，因此当访问外部域名和集群内部长域名（如kubernetes.default.svc.cluster.local）时，大部分域名都会优先遍历search搜索域列表，导致至少有6次无效的DNS查询，只有访问集群内部短域名（如kubernetes）时，才不存在无效的DNS查询。 ClusterFirstWithHostNet 对于配置主机网络的应用，即设置hostNetwork字段为true时，默认对接kubelet的“--resolv-conf”参数指向的域名解析文件（CCE集群在该配置下对接云上DNS）。如需对接集群的Kube-DNS/CoreDNS，dnsPolicy字段需设置为ClusterFirstWithHostNet，此时容器的域名解析文件配置与“ClusterFirst”一致，也存在无效的DNS查询。 ...spec: containers: - image: nginx:latest imagePullPolicy: IfNotPresent name: container-1 restartPolicy: Always hostNetwork: true dnsPolicy: ClusterFirstWithHostNet Default 容器的域名解析文件使用kubelet的“--resolv-conf”参数指向的域名解析文件（CCE集群在该配置下对接云上DNS），没有配置search搜索域列表和options。该配置只能解析注册到互联网上的外部域名，无法解析集群内部域名，且不存在无效的DNS查询。 None 设置为None之后，必须设置dnsConfig字段，此时容器的域名解析文件将完全通过dnsConfig的配置来生成。 此处如果dnsPolicy字段未被指定，其默认值为ClusterFirst，而不是Default。 dnsConfig字段说明： dnsConfig为应用设置DNS参数，设置的参数将合并到基于dnsPolicy策略生成的域名解析文件中。当dnsPolicy为“None”，应用的域名解析文件完全由dnsConfig指定；当dnsPolicy不为“None”时，会在基于dnsPolicy生成的域名解析文件的基础上，追加dnsConfig中配置的dns参数。 表2 dnsConfig字段说明 参数 说明 options DNS的配置选项，其中每个对象可以具有name属性（必需）和value属性（可选）。该字段中的内容将合并到基于dnsPolicy生成的域名解析文件的options字段中，dnsConfig的options的某些选项如果与基于dnsPolicy生成的域名解析文件的选项冲突，则会被dnsConfig所覆盖。 nameservers DNS的IP地址列表。当应用的dnsPolicy设置为“None”时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的DNS的IP列表将合并到基于dnsPolicy生成的域名解析文件的nameserver字段中，并删除重复的地址。 searches 域名查询时的DNS搜索域列表，此属性是可选的。指定后，提供的搜索域列表将合并到基于dnsPolicy生成的域名解析文件的search字段中，并删除重复的域名。Kubernetes最多允许6个搜索域。

工作负载的DNS配置实践 前面介绍了Linux系统域名解析文件以及Kubernetes为应用提供的DNS相关配置项，下面将举例介绍应用如何进行DNS配置。 场景1 对接kubernetes内置的Kube-DNS/CoreDNS 场景说明： 这种方式适用于应用中的域名解析只涉及集群内部域名，或者集群内部域名+外部域名两种方式，应用默认采用这种配置。 示例： apiVersion: v1kind: Podmetadata: namespace: default name: dns-examplespec: containers: - name: test image: nginx:alpine dnsPolicy: ClusterFirst 该配置下容器的域名解析文件将如下所示： nameserver 10.247.3.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 场景2 直接对接云DNS 场景说明： 这种方式适用于应用只访问注册到互联网的外部域名，该场景不能解析集群内部域名。 示例： apiVersion: v1kind: Podmetadata: namespace: default name: dns-examplespec: containers: - name: test image: nginx:alpine dnsPolicy: Default //使用kubelet的“--resolv-conf”参数指向的域名解析文件（CCE集群在该配置下对接云DNS） 该配置下容器的域名解析文件将如下所示： nameserver 100.125.x.x 场景3 主机网络模式的应用对接Kube-DNS/CoreDNS 场景说明： 对于配置主机网络模式的应用，默认对接云DNS，如果应用需要对接Kube-DNS/CoreDNS，需将dnsPolicy设置为“ClusterFirstWithHostNet”。 示例： apiVersion: v1kind: Podmetadata: name: nginxspec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: nginx image: nginx:alpine ports: - containerPort: 80 该配置下容器的域名解析文件将如下所示： nameserver 10.247.3.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 场景4 自定义应用的域名配置 场景说明： 用户可以完全自定义配置应用的域名解析文件，这种方式非常灵活，dnsPolicy和dnsConfig配合使用，几乎能够满足所有使用场景，如对接用户自建DNS的场景、串联多个DNS的场景以及优化DNS配置选项的场景等等。 示例1：对接用户自建DNS 该配置下，dnsPolicy为“None”，应用的域名解析文件完全根据dnsConfig配置生成。 apiVersion: v1kind: Podmetadata: namespace: default name: dns-examplespec: containers: - name: test image: nginx:alpine dnsPolicy: "None" dnsConfig: nameservers: - 10.2.3.4 //用户自建DNS的IP地址 searches: - ns1.svc.cluster.local - my.dns.search.suffix options: - name: ndots value: "2" - name: timeout value: "3" 该配置下容器的域名解析文件将如下所示： nameserver 10.2.3.4search ns1.svc.cluster.local my.dns.search.suffixoptions timeout:3 ndots:2 示例2：修改域名解析文件的ndots选项，减少无效的DNS查询 该配置下，dnsPolicy不为“None”，会在基于dnsPolicy生成的域名解析文件的基础上，追加dnsConfig中配置的dns参数。 apiVersion: v1kind: Podmetadata: namespace: default name: dns-examplespec: containers: - name: test image: nginx:alpine dnsPolicy: "ClusterFirst" dnsConfig: options: - name: ndots value: "2" //该配置会将基于ClusterFirst策略生成的域名解析文件的ndots:5参数改写为ndots:2 该配置下容器的域名解析文件将如下所示： nameserver 10.247.3.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:2

DNS配置项说明 在Linux系统的节点或者容器里执行cat /etc/resolv.conf命令，能够查看到DNS配置，以Kubernetes集群的容器DNS配置为例： nameserver 10.247.x.xsearch default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 配置项说明： nameserver：容器解析域名时查询的DNS服务器的IP地址列表。如果设置为10.247.x.x说明DNS对接到Kube-DNS/CoreDNS，如果是其他IP地址，则表示采用云上DNS或者用户自建的DNS。 search：定义域名的搜索域列表，当访问的域名不能被DNS解析时，会把该域名与搜索域列表中的域依次进行组合，并重新向DNS发起请求，直到域名被正确解析或者尝试完搜索域列表为止。对于CCE集群来说，容器的搜索域列表配置3个域，当解析一个不存在的域名时，会产生8次DNS查询，因为对于每个域名需要查询两次，分别是IPv4和IPv6。 options：定义域名解析配置文件的其他选项，常见的有timeout、ndots等等。 Kubernetes集群容器的域名解析文件设置为options ndots:5，该参数的含义是当域名的“.”个数小于ndots的值，会先把域名与search搜索域列表进行组合后进行DNS查询，如果均没有被正确解析，再以域名本身去进行DNS查询。当域名的“.”个数大于或者等于ndots的值，会先对域名本身进行DNS查询，如果没有被正确解析，再把域名与search搜索域列表依次进行组合后进行DNS查询。 如查询www.***.com域名时，由于该域名的“.”个数为2，小于ndots的值，所以DNS查询请求的顺序依次为：www.***.default.svc.cluster.local、www.***.com.svc.cluster.local、 www.***.com.cluster.local和 www.***.com，需要发起至少7次DNS查询请求才能解析出该域名的IP。可以看出，这种配置在访问外部域名时，存在大量冗余的DNS查询，存在优化点。 完整的Linux域名解析文件配置项说明可以参考文档：http://man7.org/linux/man-pages/man5/resolv.conf.5.html。

kubernetes中的域名解析逻辑 DNS策略可以在每个pod基础上进行设置，目前，Kubernetes支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种DNS策略，具体请参见https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/。这些策略在pod-specific的dnsPolicy字段中指定。

自定义CoreDNS规格 CoreDNS在插件界面仅支持按预设规格配置，通常情况下，这满足绝大多数使用场景。但在一些少数对CoreDNS资源用量有要求的场景下，不能根据需要灵活配置。 下面介绍CoreDNS参数自定义配置方法，包括副本数量、CPU/内存的大小等。 CoreDNS修改配置需额外谨慎，因为CoreDNS负责集群的域名解析任务，修改不当可能会导致集群解析出现异常。请做好修改前后的测试验证。 CoreDNS使用资源的规格与解析能力相关，修改CoreDNS副本数量、CPU/内存的大小会对影响解析性能，请经过评估后再做修改。 CoreDNS插件默认配置了podAntiAffinity（Pod反亲和），当一个节点已有一个CoreDNS Pod时无法再添加新的Pod，即一个节点上只能运行一个CoreDNS Pod。如果您配置的CoreDNS副本数量大于集群节点数量，会导致多出的Pod无法调度。建议Pod的副本数量不大于节点的数量。 调用插件查询接口查看已安装CoreDNS的插件ID。 GET https://{cluster_id}.{endpoint}/api/v3/addons?cluster_id={cluster_id} 接口调用方法请参见如何调用API，其中{cluster_id}为集群的ID，集群ID可以在控制台的集群详情页面中查看；{endpoint}为CCE的访问地址，可以从地区和终端节点获取，例如上海一区域为cce.east-3.myhuaweicloud.com。 在响应中查看CoreDNS的uid，和spec定义，如下所示。 { "kind": "Addon", "apiVersion": "v3", "items": [ { "kind": "Addon", "apiVersion": "v3", "metadata": { "uid": "2083381d-46ae-11ec-91a8-0255ac1000c5", "name": "coredns", "creationTimestamp": "2021-11-16T07:23:42Z", "updateTimestamp": "2021-11-16T07:27:35Z" }, "spec": { "clusterID": "15d748b4-3de1-11ec-9199-0255ac1000c9", "version": "1.17.9", "addonTemplateName": "coredns", "addonTemplateType": "helm",... 调用修改插件接口修改插件的规格。 PUT https://{cluster_id}.{endpoint}/api/v3/addons/{uid} 其中{cluster_id}为集群的ID；{endpoint}为CCE的访问地址，可以从地区和终端节点获取；{uid}为上一步查询到的插件ID。 请求Body示例如下，spec定义从上一步中查询到的内容，根据需求修改其中replicas（副本数量），resources（单个Pod的CPU/内存的使用量配置）；clusterID、version保持不变，addon.upgrade/type的取值必须为patch。 { "metadata": { "annotations": { "addon.upgrade/type": "patch" } }, "spec": { "clusterID": "15d748b4-3de1-11ec-9199-0255ac1000c9", "version": "1.17.9", "addonTemplateName": "coredns", "values": { "flavor": { "replicas": 2, "resources": [ { "limitsCpu": "500m", "limitsMem": "512Mi", "requestsCpu": "500m", "requestsMem": "512Mi" } ] } } }}

升级插件 登录CCE控制台，在左侧导航栏中选择“插件管理”，在“插件实例”页签下，选择对应的集群，单击coredns下的“升级”。 如果升级按钮处于冻结状态，则说明当前插件版本是最新的版本，不需要进行升级操作。 升级时之前的配置会丢失，需要重新配置。 升级coredns插件时，会替换原先节点上的旧版本的coredns插件，安装最新版本的coredns插件以实现功能的快速升级。如果升级出现异常，请卸载插件后重新安装和配置。 在基本信息页面选择插件版本，单击“下一步”。 参照表2配置插件安装参数。配置完成后，单击“升级”即可升级coredns插件。 表2 安装插件说明 参数 参数说明 插件规格 并发域名解析能力。请根据业务需求选择插件规格。 存根域 用户可对自定义的域名配置域名服务器，格式为一个键值对，键为DNS后缀域名，值为一个或一组DNS IP地址，如"acme.local -- 1.2.3.4,6.7.8.9"。

为CoreDNS配置存根域 集群管理员可以修改CoreDNS Corefile的ConfigMap以更改服务发现的工作方式。使用插件proxy可对CoreDNS的存根域进行配置。 若集群管理员有一个位于10.150.0.1的Consul域名解析服务器，并且所有Consul的域名都带有.consul.local的后缀。 执行以下命令，在CoreDNS的ConfigMap中添加如下信息即可将该域名服务器配置在CoreDNS中： kubectl edit configmap coredns -n kube-system 参照下方示例进行配置： consul.local:5353 { errors cache 30 proxy . 10.150.0.1 } v1.15.11及之后的集群版本，修改后最终的ConfigMap如下所示： apiVersion: v1metadata: name: coredns namespace: kube-system selfLink: /api/v1/namespaces/kube-system/configmaps/coredns uid: 00cb8f29-62d7-4df8-a769-0a16237903c1 resourceVersion: '2074614' creationTimestamp: '2021-04-07T03:52:42Z' labels: app: coredns k8s-app: coredns kubernetes.io/cluster-service: 'true' kubernetes.io/name: CoreDNS release: cceaddon-corednsdata: Corefile: |- .:5353 { bind {$POD_IP} cache 30 errors health {$POD_IP}:8080 kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream /etc/resolv.conf fallthrough in-addr.arpa ip6.arpa } loadbalance round_robin prometheus {$POD_IP}:9153 forward . /etc/resolv.conf reload } consul.local:5353 { errors cache 30 proxy . 10.150.0.1 } 1.15.11之前的集群版本，修改后最终的ConfigMap如下所示： apiVersion: v1data: Corefile: |- .:5353 { cache 30 errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream /etc/resolv.conf fallthrough in-addr.arpa ip6.arpa } loadbalance round_robin prometheus 0.0.0.0:9153 proxy . /etc/resolv.conf reload } consul.local:5353 { errors cache 30 proxy . 10.150.0.1 }kind: ConfigMapmetadata: name: coredns namespace: kube-system

插件简介 CoreDNS插件是一款通过链式插件的方式为Kubernetes提供域名解析服务的DNS服务器。 CoreDNS是由CNCF孵化的开源软件，用于Cloud-Native环境下的DNS服务器和服务发现解决方案。CoreDNS实现了插件链式架构，能够按需组合插件，运行效率高、配置灵活。在kubernetes集群中使用CoreDNS能够自动发现集群内的服务，并为这些服务提供域名解析。同时，通过级联云上的DNS服务器，还能够为集群内的工作负载提供外部域名的解析服务。 该插件为系统资源插件，kubernetes 1.11及以上版本的集群在创建时默认安装。 目前CoreDNS已经成为社区kubernetes 1.11及以上版本集群推荐的DNS服务器解决方案。 CoreDNS官网：https://coredns.io/ 开源社区地址：https://github.com/coredns/coredns DNS详细使用方法请参见工作负载DNS配置说明。

安装插件 本插件为系统默认安装，若因特殊情况卸载后，可参照如下步骤重新安装。 登录CCE控制台，在左侧导航栏中选择“插件管理”，在“插件市场”页签下，单击coredns插件下的“安装插件”。 在安装插件页面，选择安装的集群和插件版本，单击“下一步：规格配置”。 在“规格配置”步骤中，可配置如下参数： 表1 coredns插件参数配置 参数 参数说明 插件规格 并发域名解析能力，请根据业务需求选择插件规格。 实例数 选择上方插件规格后，显示插件中的实例数，此处仅作显示。 容器 选择插件规格后，显示插件容器的CPU和内存配额，此处仅作显示。 提示 关于本插件的注意事项，请仔细阅读。 存根域 单击“添加”，您可对自定义的域名配置域名服务器，格式为一个键值对，键为DNS后缀域名，值为一个或一组DNS IP地址，如"acme.local -- 1.2.3.4,6.7.8.9"。 完成以上配置后，单击“安装”。 待插件安装完成后，单击“返回”，在“插件实例”页签下，选择对应的集群，可查看到运行中的实例，这表明该插件已在当前集群的各节点中安装。

收缩web-terminal权限 web-terminal插件安装后，其kubectl默认使用cluster-admin ClusterRole权限，能够操作该集群k8s资源，若需手动配置为其他类型权限，可通过kubectl edit clusterrolebinding web-terminal修改web-terminal ServiceAccount绑定其他权限的ClusterRole。 ClusterRole、ClusterRoleBinding相关配置说明请参见命名空间权限（Kubernetes RBAC授权）。 手动配置的web-terminal权限在web-terminal插件升级时存在被重置风险，需注意做好备份在插件升级后重新配置。 使用kubectl修改clusterrolebinding配置需确保当前kubectl有修改clusterrolebinding资源操作权限。

安装插件 登录CCE控制台，单击左侧导航栏的“ 插件管理”，在“插件市场”页签下，单击web-terminal插件下的“安装插件”。 在安装插件页面，选择安装的集群和插件版本，单击“下一步：规格配置”。 在规格配置页面，配置以下参数。 用户名：默认为root，不可修改。 密码：登录web-terminal的密码，请务必记住该密码。web-terminal插件能够对CCE集群进行管理，请用户妥善保管好登录密码，避免密码泄漏造成损失。 确认密码：重新准确输入该密码。 访问类型： 节点访问：该插件默认以NodePort形式提供访问，需为集群任意一个节点绑定弹性IP才能使用。若集群没有绑定弹性IP，需绑定弹性IP。 负载均衡：选择弹性负载均衡实例。若无弹性负载均衡实例，需新建共享型弹性负载均衡，完成后单击刷新按钮。负载均衡实例需与当前集群处于相同VPC且为公网类型。 端口配置：访问类型为负载均衡时，需端口配置。 协议：固定为TCP。 容器端口：容器镜像中工作负载实际监听端口，为默认值，无法更改。 访问端口：容器端口最终映射到负载均衡服务地址的端口，用负载均衡服务地址访问工作负载时使用，端口范围为1-65535，可任意指定。 单击“安装”。 待插件安装完成后，单击“返回”，在“插件实例”页签下，选择对应的集群，可查看到运行中的实例，这表明该插件已在当前集群的各节点中安装。

升级插件 登录CCE控制台，在左侧导航栏中选择“插件管理”，在“插件实例”页签下，选择对应的集群，单击“web-terminal”下的“ 升级”。 如果升级按钮处于冻结状态，则说明当前插件版本是最新的版本，不需要进行升级操作。 升级“web-terminal”插件时，会替换原先节点上的旧版本的“web-terminal”插件，安装最新版本的“web-terminal”插件以实现功能的快速升级。 在基本信息页面选择插件版本，单击“下一步”。 参考安装插件中参数说明配置参数后，单击“升级”即可升级“web-terminal”插件。

约束与限制 仅支持在1.9及以上版本的集群中安装此插件，暂不支持鲲鹏集群。 web-terminal插件当前版本处于beta阶段中，后续将使用cloudshell方案代替，请根据实际场景选择体验。 web-terminal中kubectl具有高级别操作权限，限帐号以及具有CCE Administrator权限的IAM用户安装此插件，如需收缩插件中kubectl权限，请参见收缩web-terminal权限操作。 web-terminal当前仅支持部署在x86计算节点，鲲鹏计算节点可使用kubectl直接对接集群。 集群必须安装CoreDNS才能使用web-terminal。