更新时间:2024-10-15 GMT+08:00

插件管理

kubernetes除了必要的支撑组件以外,其他的组件都是以插件的形式运行,如Kubernetes DNS,Kubernetes Dashboard等等。

插件是对现有功能的扩展,当前云容器实例提供了coredns插件供您使用,您可以在云容器实例界面上直接安装插件,从而方便的使用插件提供的功能。

coredns插件介绍

coredns插件为您的其他负载提供内部域名解析服务。建议您不要对本负载进行删除、升级操作,否则将导致内部域名解析服务无法正常使用。

安装插件

  1. 登录云容器实例管理控制台,左侧导航栏中选择“插件管理 > 插件市场”,单击右侧页面

    图1 coredns插件

  2. 选择“插件版本”,单击“提交”安装插件。

    1. 安装2.5.9及以上版本的coredns插件时,还需配置如下参数:
      • 存根域:单击“添加”,您可对自定义的域名配置域名服务器,格式为一个键值对,键为DNS后缀域名,值为一个或一组DNS IP地址,如"acme.local -- 1.2.3.4,6.7.8.9"。
      • 上游域名服务器:解析除集群内服务域名及自定义域名之外的域名地址,格式为一个或一组DNS IP地址,例如"8.8.8.8","8.8.4.4"。
    2. 安装2.5.10及以上版本的coredns插件时,还可配置如下参数:
      • 日志输出选项:您可根据业务需要,灵活配置需要打印的域名解析日志类别,便于发现问题,例如“输出解析成功日志”、“输出解析错误日志”,查看日志输出选项含义

    安装完成后,您可以在“插件管理 > 插件实例”中看到已安装的插件,如图。

    图2 coredns插件安装成功

为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 Corefile的ConfigMap以更改服务发现的工作方式。使用插件proxy可对CoreDNS的存根域进行配置。

为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

查看解析日志

在配置解析日志插件后,可以通过AOM服务查看解析日志。

  1. 在云容器实例管理控制台,左侧导航栏中选择“插件管理 > 插件实例”,右侧选择“CoreDNS”插件,进入CoreDNS插件页面。

    图4 插件实例列表

  2. 单击资源列表中的coredns Deployment 进入pod列表。

    图5 CoreDNS Deployment

  3. 在pod列表的操作一栏中选择“查看日志”选项,即可在AOM界面中查看coredns的日志。

    图6 Pod列表

kubernetes中的域名解析逻辑

DNS策略可以在每个pod基础上进行设置,目前,Kubernetes支持DefaultClusterFirstClusterFirstWithHostNetNone四种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 查询将基于下面的流程对请求进行路由:
    1. 查询首先被发送到 coredns 中的 DNS 缓存层。
    2. 从缓存层,检查请求的后缀,并根据下面的情况转发到对应的 DNS 上:
      • 具有集群后缀的名字(例如“.cluster.local”):请求被发送到 coredns。
      • 具有存根域后缀的名字(例如“.acme.local”):请求被发送到配置的自定义 DNS 解析器(例如:监听在 1.2.3.4)。
      • 未能匹配上后缀的名字(例如“widget.com”):请求被转发到上游 DNS。
    图7 路由请求流程

后续处理

插件安装成功后,您还可以对插件做如下操作。

表1 其他操作

操作

说明

升级

单击,选择要升级的目标版本,然后单击“下一步”,确认新的配置信息,单击“提交”

回退

单击,选择要回退的目标版本,单击“提交”

删除

单击,然后单击“确认”

须知:

删除操作无法恢复,请谨慎操作。

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.25.14

v1.19

v1.21

v1.23

v1.25

  • 支持插件规格与集群规格联动
  • 插件与节点时区一致

1.10.1

1.25.11

v1.19

v1.21

v1.23

v1.25

  • 支持插件实例AZ反亲和配置
  • 升级至社区版本 1.10.1

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