云服务器内容精选

  • 操作步骤 安装“云原生日志采集插件”和“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挂载多种类型存储目录 pod通过指定系统、设备、cgroup、tmpfs等挂载目录下的日志无法被采集。 弹性CCI的pod关联多个日志采集策略 为了更好的采集日志,建议为pod预留充足内存。pod被第一个日志策略关联请预留至少50MB内存。每增加一个关联日志采集策略,建议多预留5MB内存。 超长日志采集 单条日志最大容量为250KB,超过会被丢弃。 超长日志文件名 容器中长度超过190的日志文件无法被采集。 日志采集策略中,最长文件名不能超过255。
  • 问题一:用户负载无法调度到CCI,登录CCE节点执行kubectl get node发现virtual-kubelet节点状态为不可调度。 问题原因:CCI资源售罄导致弹性到CCI的资源调度失败,bursting节点会被锁定半小时(状态变为SchedulingDisabled),期间无法调度至CCI。 解决方案:用户可通过CCE集群控制台,使用kubectl工具查看bursting节点状态,若节点被锁定,可手动解锁bursting节点。
  • 命名空间权限 Kubernetes RBAC API定义了四种类型:Role、ClusterRole、RoleBinding与ClusterRoleBinding。当前CCI仅支持ClusterRole、RoleBinding,这两种类型之间的关系和简要说明如下: ClusterRole:描述角色和权限的关系。在Kubernetes的RBAC API中,一个角色定义了一组特定权限的规则。整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。 RoleBinding:描述subjects(包含users,groups)和角色的关系。角色绑定将一个角色中定义的各种权限授予一个或者一组用户,该用户或用户组则具有对应绑定ClusterRole定义的权限。 表1 RBAC API所定义的两种类型 类型名称 说明 ClusterRole ClusterRole对象可以授予整个集群范围内资源访问权限。 RoleBinding RoleBinding可以将同一Namespace中的subject(用户)绑定到某个具有特定权限的ClusterRole下,则此subject即具有该ClusterRole定义的权限。 当前仅支持用户使用ClusterRole在Namespace下创建RoleBinding。
  • CoreDNS域名解析插件版本发布记录 表2 CoreDNS域名解析插件版本记录 插件版本 支持的集群版本 更新特性 社区版本 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 路由请求流程
  • 为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
  • 使用SWR拉取用户业务镜像 方式一:通过console选取SWR镜像 用户镜像上传SWR。使用方式请参考:SWR官方文档。 在华为云CCE控制台创建负载选择镜像。 对接到SWR中的镜像。请确保您的SWR仓库中已正确上传了镜像,SWR服务使用详情请参见:SWR官方文档。 方式二:通过在CCE集群node选取SWR镜像 登录CCE集群节点。 查看SWR镜像仓库中的镜像地址。 获取镜像地址:swr.cn-north-7.myhuaweicloud.com/cci-test/nginx:1.0.0.x86_64_test。 配置工作负载yaml。 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: swr.cn-north-7.myhuaweicloud.com/cci-test/nginx:1.0.0.x86_64_test name: container-0 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi volumeMounts: [] imagePullSecrets: - name: default-secret 部署工作负载。 kubectl apply -f dep.yaml
  • 使用第三方镜像拉取用户业务镜像 使用CCI提供的工具创建第三方镜像仓库认证secret。 imagepull-secret-generator --ak=$ak --sk=$sk --private-user=$user --private-password=$password --output-file-path=my-imagepull-secret.json --project-name=cn-north-4 --secret-name=my-imagepull-secret --swr-address=swr.cn-north-4.myhuaweicloud.com 登录CCE集群节点,为集群创建secret。 kubectl apply -f my-imagepull-secret.json 创建负载,使用secret。 在spec.imagePullSecrets中指定第三方仓库认证secret。 apiVersion: apps/v1 kind: Deployment metadata: labels: app: test-imagepull virtual-kubelet.io/burst-to-cci: enforce name: test-imagepull spec: replicas: 1 selector: matchLabels: app: test-imagepull template: metadata: labels: app: test-imagepull spec: containers: - image: xxx/my-image:latest imagePullPolicy: Always name: nginx resources: limits: cpu: 1 memory: 2Gi requests: cpu: 1 memory: 2Gi imagePullSecrets: - name: my-imagepull-secret
  • CCE集群pod与CCI集群中pod通过service互通的使用指导 安装插件,勾选”网络互通“功能。 安装成功后租户账号下会自动创建负载均衡器,可以通过网络控制台进行查看。 创建弹性CCI侧pod,并配置service发布。 为了方便验证,镜像选择暴露容器80端口的nginx。 为工作负载配置service。推荐自动创建新的负载均衡器,以避免和插件自动创建的elb产生冲突。 通过CCE集群控制台,获取该负载的访问方式。 创建CCE侧pod,并配置service发布。方法请参考步骤2,不选择弹性CCI标签。 验证网络互访。 创建弹性CCI的工作负载,镜像选择含有curl命令的镜像,如centos。 通过CCI侧进入该容器,执行图中命令,观测CCI访问CCE service网络打通。 图1 访问CCI pod的service 图2 访问CCE pod的service 同理创建CCE侧pod,镜像选择含有curl命令的镜像,如centos。执行相同的命令。观测CCE访问CCI service网络打通。
  • 安装插件 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件,单击“安装”。 配置插件参数。 表1 插件参数说明 插件参数 说明 选择版本 插件的版本。插件版本和CCE集群存在配套关系,更条信息可以参考CCE突发弹性引擎(对接CCI)插件版本记录。 规格配置 用于配置插件负载的实例数。 网络互通 勾选后将开启CCE集群和CCI两侧pod互访的功能,用户可以根据自身业务选择是否打开。详细功能介绍请参考网络。
  • 工作负载下发 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“工作负载”,进入工作负载首页。 单击“创建工作负载”,具体操作步骤详情请参见创建工作负载。 填写基本信息。“CCI弹性承载”选择“强制调度策略”。关于调度策略更多信息,请参考调度负载到CCI。 进行容器配置。 配置完成后,单击“创建工作负载”。 在工作负载页面,选择工作负载名称,单击进入工作负载管理界面。 工作负载所在节点为CCI集群,说明负载成功已调度到CCI。
  • 插件卸载 登录CCE控制台。 选择CCE集群,单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”,进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件,单击“卸载”。 表2 特殊场景说明 特殊场景描述 场景现象 场景说明 CCE集群无节点,卸载插件。 插件卸载失败。 bursting插件卸载时会在集群中启动Job用于清理资源,卸载插件时请保证集群中至少有一个可以调度的节点。 用户直接删除集群,未卸载插件。 用户在CCI侧的命名空间中有资源残留,如果命名空间有计费资源,会造成额外计费。 由于直接删除集群,没有执行插件的资源清理Job,造成资源残留。用户可以手动清除残留命名空间及其下的计费资源来避免额外计费。 关于CCE突发弹性引擎(对接CCI)更多内容详情请参见:CCE突发弹性引擎(对接CCI)。
  • 简介 CCE突发弹性引擎(对接 CCI)作为一种虚拟的kubelet用来连接Kubernetes集群和其他平台的API。Bursting的主要场景是将Kubernetes API扩展到无服务器的容器平台(如CCI)。 基于该插件,支持用户在短时高负载场景下,将部署在云容器引擎CCE上的无状态负载(Deployment)、有状态负载(StatefulSet)、普通任务(Job)、定时任务(CronJob)四种资源类型的容器实例(Pod),弹性创建到云容器实例CCI服务上,以减少集群扩容带来的消耗。