插件管理

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

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

coredns插件介绍

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

安装插件

登录云容器实例管理控制台，左侧导航栏中选择插件管理 > 插件市场，单击右侧页面。
图1 coredns插件
选择“插件版本”，单击“提交”安装插件。
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服务查看解析日志。

在云容器实例管理控制台，左侧导航栏中选择选择“插件管理 > 插件实例”，右侧选择“CoreDNS”插件，进入CoreDNS插件页面：
图4 插件实例列表
单击资源列表中的coredns Deployment 进入pod列表
图5 CoreDNS Deployment
在pod列表的操作一栏中选择“查看日志”选项，即可在AOM界面中查看coredns的日志。
图6 Pod列表

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 查询将基于下面的流程对请求进行路由：
1. 查询首先被发送到 coredns 中的 DNS 缓存层。
2. 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上：
  - 具有集群后缀的名字（例如“.cluster.local”）：请求被发送到 coredns。
  - 具有存根域后缀的名字（例如“.acme.local”）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。
  - 未能匹配上后缀的名字（例如“widget.com”）：请求被转发到上游 DNS。
图7 路由请求流程

后续处理

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

表1 其他操作
操作	说明
升级	单击，选择要升级的目标版本，然后单击“下一步”，确认新的配置信息，单击“提交”。
回退	单击，选择要回退的目标版本，单击“提交”。
删除	单击，然后单击“确认”。须知：删除操作无法恢复，请谨慎操作。