云服务器内容精选

  • 操作步骤 安装“云原生日志采集插件”和“CCE 突发弹性引擎 (对接 CCI)”插件。 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件,单击“安装”。 在安装配置中需要勾选“网络互通”功能。 选择“云原生日志采集插件”,单击“安装”。 创建弹性到CCI的负载。 在导航栏左侧单击“工作负载”,进入工作负载首页。 单击“创建工作负载”,具体操作步骤详情请参见创建工作负载。 填写基本信息并完成工作负载创建。更多创建弹性到CCI负载的方式,请参考调度负载到CCI。 配置日志采集策略。 在导航栏左侧单击“日志中心”,进入日志中心首页。 单击“日志采集策略”,进入日志采集策略创建的界面。 配置具体日志采集策略,完成后单击“确定”。 弹性到CCI的Pod不支持日志策略热更新,更新日志采集策略后需要重新部署弹性到CCI的Pod才可生效。 查看弹性到CCI的pod yaml。 为支持CCI pod日志被采集到日志中心,CCE插件CCE Log Collector为pod注入了如下四个annotation: annotation 示例值 coordinator.cci.io/inject-volumes '[{"name":"log-agent-conf","configMap":{"name":"log-agent-cci-logging-config","defaultMode":384},"namespace":"monitoring"},{"name":"log-agent-cert","secret":{"secretName":"log-agent-ca-secret","defaultMode":384},"namespace":"monitoring"}]' logconf.k8s.io/fluent-bit-configmap-reference monitoring-log-agent-cci-logging-config logconfigs.logging.openvessel.io '{"testcci001":{"container_files":{"container-1":"/var/test/*/*.log"},"regulation":""}}'' sandbox-volume.openvessel.io/volume-names log-agent-conf,log-agent-cert 在日志中心查看日志上报。 CCE集群日志中心更详细的用法可以参考CCE插件CCE Log Collector相关文档指导。
  • 约束与限制 使用场景 使用说明 CCE内容器日志采集 + CCI集群容器日志采集 CCE集群内的工作负载支持三种日志采集类型: 容器标准输出:采集集群内指定容器日志,仅支持Stderr和Stdout的日志。 容器文件日志:采集集群内指定容器内的文件日志。 节点文件日志:采集集群内指定节点路径的文件。 须知: 弹性到CCI的工作负载仅支持“容器文件日志”类型的采集策略。 不支持采集的日志文件类型 不支持容器中软链路径的日志采集。 pod通过指定系统、设备、cgroup、tmpfs等挂载目录下的日志无法被采集。 弹性CCI的pod关联多个日志采集策略 为了更好的采集日志,建议为pod预留充足内存。pod被第一个日志策略关联请预留至少50MiB内存。每增加一个关联日志采集策略,建议多预留5MiB内存。 超长日志采集 单条日志最大容量为250KB,超过会被丢弃。 超长日志文件名 容器中长度超过190的日志文件无法被采集。容器中长度在180~190范围的日志文件仅支持采集第一个文件。 日志采集速率 单个Pod单行日志采集速率不超过10000条/秒,多行日志不超过2000条/秒。 最大采集文件数 单个Pod所有日志采集策略监听的文件数不超过2000个文件。 容器停止前日志采集 当容器被停止时,如果出现因网络延迟、资源占用多等原因导致的采集延时,可能会丢失容器停止前的部分日志。
  • 简介 CCE集群成功将负载弹性到CCI运行起负载后,用户可以通过CCE的“CCE Log Collector”插件来收集pod的日志,提升工作负载的可观测性。通过阅读本章用户可以快速搭建日志平台,在CCE的日志观测CCI侧日志。 弹性到CCI的负载会默认开启容器标准输出采集并上报到 应用运维管理 AOM 每月赠送每个租户500M的免费日志存储空间,超过500M时将根据实际使用量进行收费,计费规则请参见产品价格详情。 若要关闭标准输出采集可通过在Pod annotation中指定log.stdoutcollection.kubernetes.io: '{"collectionContainers": []}'实现,参考示例: kind: Deployment apiVersion: apps/v1 metadata: name: test namespace: default spec: replicas: 1 template: metadata: annotations: log.stdoutcollection.kubernetes.io: '{"collectionContainers": []}' spec: containers: - name: container-1 image: nginx:latest
  • 方式二:使用profile控制pod调度到CCI 登录集群节点,配置profile资源。 vi profile.yaml 限制CCE集群最大负载数,配置local maxNum和scaleDownPriority的profile模板示例如下: apiVersion: scheduling.cci.io/v1 kind: ScheduleProfile metadata: name: test-cci-profile namespace: default spec: objectLabels: matchLabels: app: nginx strategy: localPrefer location: local: maxNum: 20 # 当前暂不支持local/cci同时配置maxNum scaleDownPriority: 10 cci: {} 限制CCI集群最大负载数,配置cci maxNum和scaleDownPriority的profile的模板示例如下: apiVersion: scheduling.cci.io/v1 kind: ScheduleProfile metadata: name: test-cci-profile namespace: default spec: objectLabels: matchLabels: app: nginx strategy: localPrefer location: local: {} cci: maxNum: 20 # 当前暂不支持local/cci同时配置maxNum scaleDownPriority: 10 strategy:调度策略选择。可配置策略值:auto、enforce、localPrefer。详情请参见调度策略。 location内可配置线下IDC和云上pod限制数量maxNum和pod缩容优先级scaleDownPriority,maxNum取值范围[0~int32],scaleDownPriority取值范围[-100, 100]。 local字段和cci字段不可以同时设置maxNum。 缩容优先级为非必填项参数,如果不配置缩容优先级,默认值将为空。
  • 约束与限制 当前只有负载的原生标签能够被ScheduleProfile匹配,使负载能够被ScheduleProfile管理,将CCE集群的Pod调度到CCI。例如通过ExtensionProfile加到负载上的标签不能够被ScheduleProfile匹配,因此不会被ScheduleProfile管理调度功能。 当弹性到CCI的资源调度失败时,bursting节点会被锁定半小时,期间无法调度至CCI。用户可通过CCE集群控制台,使用kubectl工具查看bursting节点状态,若节点被锁定,可手动解锁bursting。
  • 方式一:通过配置labels控制pod调度到CCI 通过CCE集群控制台(console)创建pod调度到CCI。通过CCE集群创建工作负载时,选择CCI弹性承载策略配置,选择“不开启”以外的任意策略。 在CCE集群控制台(console)创建工作负载时,CCI弹性承载支持勾选“bursting-node”或者“virtual-kubelet”,如果使用CCI 1.0请勾选“virtual-kubelet”,如果使用CCI 2.0请勾选“bursting-node”。目前CCI 2.0仅对白名单用户开放,如需使用CCI2.0服务,请提交工单申请开启CCI2.0服务。 通过yaml文件在CCE集群节点创建pod调度CCI。成功安装bursting插件后,登录CCE集群节点,在工作负载的yaml文件中添加virtual-kubelet.io/burst-to-cci标签。 apiVersion: apps/v1 kind: Deployment metadata: name: test namespace: default labels: virtual-kubelet.io/burst-to-cci: 'auto' # 弹性到CCI spec: replicas: 2 selector: matchLabels: app: test template: metadata: labels: app: test spec: containers: - image: 'nginx:perl' name: container-0 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi volumeMounts: [] imagePullSecrets: - name: default-secret
  • 为CoreDNS配置日志输出选项 CoreDNS使用log插件将 域名 解析日志打印到标准输出,可通过配置日志输出选项灵活定义输出的日志内容,可在AOM中查看解析日志。在域名解析请求量较大的业务场景下,频繁打印域名解析日志到标准输出可能会对CoreDNS的性能造成明显的影响。 当前log插件支持解析成功、解析失败和解析错误三种日志输出选项配置,如图: 图3 选项配置 对应的后端配置格式如下: log [NAMES...] [FORMAT] { class CLASSES... } CLASSES表示应记录的响应类别,是一个以空格分隔的列表。 日志输出选项配置具体含义如下: 输出解析成功日志: 勾选后将在log插件CLASSES中添加success响应参数,CoreDNS会将解析成功的日志打印到标准输出。 输出解析失败日志: 勾选后将在log插件CLASSES中添加denial响应参数, CoreDNS会将解析失败的日志,例如NXDOMAIN或nodata响应(名称存在,类型不存在)打印到标准输出。 输出解析错误日志: 勾选后将在log插件CLASSES中添加error响应参数,CoreDNS会将解析错误的日志打印到标准输出,例如SERVFAIL、NOTIMP、REFUSED等任何表示远程服务器不解析的请求消息,便于及时发现DNS服务器不可用等问题。 全不勾选: 如果未选中上述任一配置,则将关闭日志插件。 关闭日志插件仅影响CoreDNS的解析记录,而CoreDNS服务进程的日志记录依然会显示,不过该部分日志量极小,对性能无影响。 以勾选“输出解析成功日志”与“输出解析失败日志”为例,其后端log插件配置为: log . { class success denial } 创建成功的CoreDNS对应的ConfigMap如下: apiVersion: v1 data: Corefile: |- .:5353 { cache 30 errors log . { classes success denial } 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 } kind: ConfigMap metadata: name: coredns namespace: kube-system
  • 为CoreDNS配置存根域 集群管理员可以修改CoreDNS Corefile的ConfigMap以更改服务发现的工作方式。使用插件proxy可对CoreDNS的存根域进行配置。 如果集群管理员有一个位于10.150.0.1的Consul域名解析服务器,并且所有Consul的域名都带有.consul.local的后缀。在CoreDNS的ConfigMap中添加如下信息即可将该域名服务器配置在CoreDNS中: consul.local:5353 { errors cache 30 proxy . 10.150.0.1 } 修改后最终的ConfigMap如下所示: apiVersion: v1 data: 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: ConfigMap metadata: name: coredns namespace: kube-system
  • CoreDNS域名解析插件版本发布记录 表2 CoreDNS域名解析插件版本记录 插件版本 支持的集群版本 更新特性 社区版本 1.30.6 v1.21 v1.23 v1.25 v1.27 v1.28 v1.29 v1.30 支持Corefile配置 适配CCE v1.30集群 1.10.1 1.29.5 v1.21 v1.23 v1.25 v1.27 v1.28 v1.29 修复部分问题 1.10.1 1.29.4 v1.21 v1.23 v1.25 v1.27 v1.28 v1.29 适配CCE v1.29集群 1.10.1 1.28.7 v1.21 v1.23 v1.25 v1.27 v1.28 支持插件热更新配置,无需滚动升级 1.10.1 1.28.5 v1.21 v1.23 v1.25 v1.27 v1.28 修复部分问题 1.10.1 1.28.4 v1.21 v1.23 v1.25 v1.27 v1.28 适配CCE v1.28集群 1.10.1 1.27.4 v1.19 v1.21 v1.23 v1.25 v1.27 - 1.10.1 1.27.1 v1.19 v1.21 v1.23 v1.25 v1.27 适配CCE v1.27集群 1.10.1 1.25.1 v1.19 v1.21 v1.23 v1.25 适配CCE v1.25集群 1.8.4 1.23.3 v1.15 v1.17 v1.19 v1.21 v1.23 插件依赖例行升级 1.8.4 1.23.2 v1.15 v1.17 v1.19 v1.21 v1.23 插件依赖例行升级 1.8.4 1.23.1 v1.15 v1.17 v1.19 v1.21 v1.23 适配CCE v1.23集群 1.8.4 1.17.15 v1.15 v1.17 v1.19 v1.21 适配CCE v1.21集群 1.8.4 1.17.9 v1.15 v1.17 v1.19 插件依赖例行升级 1.8.4 1.17.7 v1.15 v1.17 v1.19 同步至社区v1.8.4版本 1.8.4 1.17.4 v1.17 v1.19 适配CCE v1.19集群 1.6.5 1.17.3 v1.17 支持v1.17集群,修复存根域配置问题 1.6.5 1.17.1 v1.17 支持v1.17集群 1.6.5
  • kubernetes中的域名解析逻辑 DNS策略可以在每个pod基础上进行设置,目前,Kubernetes支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种DNS策略,具体请参见https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/。这些策略在pod-specific的dnsPolicy 字段中指定。 “Default”:如果dnsPolicy被设置为“Default”,则名称解析配置将从pod运行的节点继承。 自定义上游域名服务器和存根域不能够与这个策略一起使用。 “ClusterFirst”:如果dnsPolicy被设置为“ClusterFirst”,任何与配置的集群域后缀不匹配的DNS查询(例如,www.kubernetes.io)将转发到从该节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游DNS服务器。 “ClusterFirstWithHostNet”:对于使用hostNetwork运行的Pod,您应该明确设置其DNS策略“ClusterFirstWithHostNet”。 “None”:它允许Pod忽略Kubernetes环境中的DNS设置。应使用dnsConfigPod规范中的字段提供所有DNS设置 。 Kubernetes 1.10及以上版本,支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种策略;低于Kubernetes 1.10版本,仅支持default、ClusterFirst和ClusterFirstWithHostNet三种。 “Default”不是默认的DNS策略。如果dnsPolicy的Flag没有特别指明,则默认使用“ClusterFirst”。 路由请求流程: 未配置存根域:没有匹配上配置的集群域名后缀的任何请求,例如 “www.kubernetes.io”,将会被转发到继承自节点的上游域名服务器。 已配置存根域:如果配置了存根域和上游 DNS 服务器,DNS 查询将基于下面的流程对请求进行路由: 查询首先被发送到 coredns 中的 DNS 缓存层。 从缓存层,检查请求的后缀,并根据下面的情况转发到对应的 DNS 上: 具有集群后缀的名字(例如“.cluster.local”):请求被发送到 coredns。 具有存根域后缀的名字(例如“.acme.local”):请求被发送到配置的自定义 DNS 解析器(例如:监听在 1.2.3.4)。 未能匹配上后缀的名字(例如“widget.com”):请求被转发到上游 DNS。 图7 路由请求流程
  • 操作步骤 安装“云原生监控插件”。 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“云原生监控插件”,单击“安装”。 图1 安装云原生监控插件 在安装插件页面,进行规格配置,部署模式选择“Server模式”。 如果需要在Agent部署模式下使用HPA功能,请联系技术支持人员。 通过云原生监控插件,提供系统资源指标。 如果CCE集群中未安装metrics-server插件,请开启Metric API,详情请参见通过Metrics API提供资源指标。配置完成后,可使用Prometheus采集系统资源指标。 如果CCE集群中已安装metrics-server插件,可以选择以下任意一种方式进行处理: 方式一:请卸载“Kubernetes Metrics Server”插件后,开启Metric API。 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“Kubernetes Metrics Server”插件,单击“卸载”。 开启Metric API,详情请参见通过Metrics API提供资源指标。配置完成后,可使用Prometheus采集系统资源指标。 方式二:修改APIService对象。 需要更新APIService对象“v1beta1.metrics.k8s.io”: apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: labels: app: custom-metrics-apiserver release: cceaddon-prometheus name: v1beta1.metrics.k8s.io spec: group: metrics.k8s.io groupPriorityMinimum: 100 insecureSkipTLSVerify: true service: name: custom-metrics-apiserver namespace: monitoring port: 443 version: v1beta1 versionPriority: 100 可以将该对象保存为文件,命名为metrics-apiservice.yaml,然后执行以下命令: kubectl apply -f metrics-apiservice.yaml 执行kubectl top pod -n monitoring命令,如果显示如下,则表示Metrics API能正常访问: # kubectl top pod -n monitoring NAME CPU(cores) MEMORY(bytes) ...... custom-metrics-apiserver-d4f556ff9-l2j2m 38m 44Mi ...... 卸载插件时,需要执行以下kubectl命令,同时删除APIService对象,否则残留的APIService资源将导致metrics-server插件安装失败。 kubectl delete APIService v1beta1.metrics.k8s.io
  • 插件卸载 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件,单击“卸载”。 表2 特殊场景说明 特殊场景描述 场景现象 场景说明 CCE集群无节点,卸载插件。 插件卸载失败。 bursting插件卸载时会在集群中启动Job用于清理资源,卸载插件时请保证集群中至少有一个可以调度的节点。 用户直接删除集群,未卸载插件。 用户在CCI侧的命名空间中有资源残留,如果命名空间有计费资源,会造成额外计费。 由于直接删除集群,没有执行插件的资源清理Job,造成资源残留。用户可以手动清除残留命名空间及其下的计费资源来避免额外计费。 关于CCE突发弹性引擎(对接CCI)更多内容详情请参见:CCE突发弹性引擎(对接CCI)。
  • 安装插件 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件,单击“安装”。 配置插件参数。 表1 插件参数说明 插件参数 说明 选择版本 插件的版本。插件版本和CCE集群存在配套关系,更多信息可以参考CCE突发弹性引擎(对接CCI)插件版本记录。 规格配置 用于配置插件负载的实例数及资源配额。 说明: CCE 突发弹性引擎 (对接 CCI) 插件在1.5.2及以上版本,将占用更多节点资源,请在升级CCE突发弹性引擎(对接 CCI)插件前预留空间配额。 单实例:需要预留一个节点,节点下至少需要有7个Pod空间配额。若开启网络互通,则需要有8个Pod空间配额。 高可用:需要预留两个节点,节点下至少需要有7个Pod空间配额,共计14个Pod空间配额。若开启网络互通,则需要有8个Pod空间配额,共计16个Pod空间配额。 弹性到CCI的业务量不同时,插件的资源占用也不相同。业务申请的POD、Secret、Congfigmap、PV、PVC会占用虚机资源。建议用户评估自己的业务使用量,按以下规格申请对应的虚机大小:1000pod+1000CM(300KB)推荐2U4G规格节点,2000pod+2000CM推荐4U8G规格节点,4000pod+4000CM推荐8U16G规格节点。 网络互通 开启后,支持CCE集群中的Pod与CCI集群中的Pod通过Kubernetes Service互通,并在插件安装时部署组件proxy。详细功能介绍请参考网络。
  • 工作负载下发 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“工作负载”,进入工作负载首页。 单击“创建工作负载”,具体操作步骤详情请参见创建工作负载。 填写基本信息。“CCI弹性承载”选择“强制调度策略”。关于调度策略更多信息,请参考调度负载到CCI。 CCE集群创建工作负载时,需要弹性到CCI,健康检查不支持配置TCP启动探针。 进行容器配置。 配置完成后,单击“创建工作负载”。 在工作负载页面,选择工作负载名称,单击进入工作负载管理界面。 工作负载所在节点为CCI集群,说明负载成功已调度到CCI。
  • 简介 CCE突发弹性引擎(对接 CCI)作为一种虚拟的kubelet用来连接Kubernetes集群和其他平台的API。Bursting的主要场景是将Kubernetes API扩展到无服务器的容器平台(如CCI)。 基于该插件,支持用户在短时高负载场景下,将部署在云容器引擎CCE上的无状态负载(Deployment)、有状态负载(StatefulSet)、普通任务(Job)、定时任务(CronJob)四种资源类型的容器实例(Pod),弹性创建到云容器实例CCI服务上,以减少集群扩容带来的消耗。