Kubernetes addons 之 coredns部署

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kubernetes addons 之 coredns部署相关的知识,希望对你有一定的参考价值。

参考技术A DNS 是 Kubernetes 的核心功能之一,通过 kube-dns 或 CoreDNS 作为集群的必备扩展来提供命名服务。

在Kubernetes集群推荐使用Service Name作为服务的访问地址,因此需要一个Kubernetes集群范围的DNS服务实现从Service Name到Cluster Ip的解析,这就是Kubernetes基于DNS的服务发现功能。

从Kubernetes 1.11开始,可使用CoreDNS作为Kubernetes的DNS插件进入GA状态,Kubernetes推荐使用CoreDNS作为集群内的DNS服务。 CoreDNS从2017年初就成为了CNCF的的孵化项目,CoreDNS的特点就是十分灵活和可扩展的插件机制,各种插件实现不同的功能,如重定向、定制DNS记录、记录日志等等。下图描述了CoreDNS的整体架构:

SRV 记录的创建是根据普通(或 Headless Service )ports 名称创建的,对于每个端口的命名,SRV记录的格式为 _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local. .对于普通的service, my-svc.my-namespace.svc.cluster.local 将解析为端口号和域名,对于
headless service,将解析成多条记录,对于service引用的每一个pod, auto-generated-name.my-svc.my-namespace.svc.cluster.local 将解析成包含端口号和域名的记录
更多内容请参考 kubernetes dns 规范
)

在Kubernetes中,我们安装的CoreDNS使用了以下默认的Corefile配置。

Upstream 用于解析指向外部主机的服务(外部服务)。

这里将 $DNS_SERVER_IP 替换成 10.0.0.2 ,将 $DNS_DOMAIN 替换成 cluster.local.

6.2 部署busybox,测试DNS功能

DNS服务是Kubernetes赖以实现服务发现的核心组件之一,默认情况下只会创建一个DNS Pod,在生产环境中我们需要对coredns进行扩容。 有两种方式:

kubernetes addons之node-problem-detector

node-problem-detector简介

node-problem-detector的作用是收集k8s集群管理中节点问题,并将其报告给apiserver。它是在每个节点上运行的守护程序。node-problem-detector可以作为DaemonSet运行,也可以独立运行。 当前,GCE集群中默认开启此扩展。

kubernetes目前问题

  • 基础架构守护程序问题:ntp服务关闭;
  • 硬件问题:CPU,内存或磁盘损坏;
  • 内核问题:内核死锁,文件系统损坏;
  • 容器运行时问题:运行时守护程序无响应
  • ...
    当kubernetes中节点发生上述问题,在整个集群中,k8s服务组件并不会感知以上问题,就会导致pod仍会调度至问题节点。

为了解决这个问题,我们引入了这个新的守护进程node-problem-detector,从各个守护进程收集节点问题,并使它们对上游层可见。一旦上游层面发现了这些问题,我们就可以讨论补救措施。

node-problem-detector的问题检测类型

当前支持的问题检测类型:

  • SystemLogMonitor
  • SystemStatsMonitor
  • CustomPluginMonitor
  • HealthChecker
    不同的检测类型通过不同的goroutine来实现,配置例子参考: https://github.com/kubernetes... 配置文件为json结尾。

检测问题上报api

node-problem-detector使用Event和NodeCondition将问题报告给apiserver。

  • NodeCondition:导致节点无法处理于Pod生命周期的的永久性问题应报告为NodeCondition。
  • Event:对pod影响有限的临时问题应作为event报告。

支持的选项

--version:显示当前版本。
--hostname-override:用于node-problem-detector的自定义节点名称,用于更新condition并发出event。 node-problem-detector首先从hostname-override获取节点名称,然后从NODE_NAME环境变量获取节点名称,最后从os.Hostname返回。

  • 对于系统日志监控器
    --config.system-log-monitor:系统日志监控器配置文件的路径列表,以逗号分隔,例如 config/kernel-monitor.json。node-problem-detector将为每个配置启动一个单独的日志监视器。 您可以使用不同的日志监视器来监视不同的系统日志。
  • 对于系统状态监控器
    --config.system-stats-monitor:系统状态监视配置文件的路径列表,以逗号分隔,例如 config / system-stats-monitor.json。 node-problem-detector将为每个配置启动一个单独的系统状态监视器。 您可以使用不同的系统状态监视器来监视与问题相关的不同系统状态。
  • 对于自定义插件监视器
    --config.custom-plugin-monitor:自定义插件监视器配置文件的路径列表,以逗号分隔,例如 config/custom-plugin-monitor.json。 node-problem-detector将为每个配置启动一个单独的自定义插件监视器。 您可以使用不同的自定义插件监视器来监视不同的节点问题。
  • Kubernetes exporter
    --enable-k8s-exporter:启用向Kubernetes API服务器报告的功能,默认为true。
    --apiserver-override:一个URI参数,用于自定义node-problem-detector连接apiserver的地址。 如果--enable-k8s-exporter为false,则忽略此内容。 格式与Heapster的源标志相同。 例如,要在没有身份验证的情况下运行,请使用以下配置: http://APISERVER_IP:APISERVER_PORT?inClusterConfig=false
    请参阅heapster文档以获取可用选项的完整列表。
    --address:绑定node-problem-detector服务器的地址。
    --port:绑定node-problem-detector服务器的端口。 使用0禁用。
  • Prometheus exporter
    --prometheus-address:绑定Prometheus抓取端点的地址,默认为127.0.0.1。
    --prometheus-port:绑定Prometheus抓取端点的端口,默认为20257。使用0禁用。
  • Stackdriver exporter

--exporter.stackdriver:Stackdriver exporter程序配置文件的路径,例如 config/exporter/stackdriver-exporter.json,默认为空字符串。 设置为空字符串以禁用。

  • END -

以上是关于Kubernetes addons 之 coredns部署的主要内容,如果未能解决你的问题,请参考以下文章

k8s集群之日志收集EFK架构

09-2.部署 dashboard 插件

09-1.部署 coredns 插件

09-5.部署 EFK 插件

Kubernetes 部署集群内部DNS服务

.NET Core + Kubernetes:Pod