k8s:为什么核心不能在主节点上运行？

Question

我建立了一个k8s集群，它有一个主节点和一个工作节点，coredns pod是对工作节点的调度，工作正常。当我删除worker节点时，coredns pod是对主节点的调度，但具有CrashLoopBackOff状态，coredns pod的日志如下所示：

E0118 10:06:02.408608       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.2/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
E0118 10:06:02.408752       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.2/tools/cache/reflector.go:105: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
[INFO] SIGTERM: Shutting down servers then terminating
[INFO] plugin/health: Going into lameduck mode for 5s

这篇文章说DNS组件必须在常规集群节点(而不是Kubernetes主节点)上运行：

除了运行在主计算机上的Kubernetes核心组件(如api-server、调度器、控制器管理器)之外，还有许多附加组件，由于各种原因，它们必须运行在常规集群节点(而不是Kubernetes主节点)上。其中一些附加组件对于一个功能齐全的集群至关重要，例如Heapster、DNS和UI。

有人能解释为什么coredns吊舱不能在主节点上运行吗？

Answer 1

从零开始，Kubernetes的想法是在工作节点上部署吊舱。主节点是控制和管理工作节点的节点。

当第一次设置Kubernetes集群时，主节点上会设置一个污点，这将自动防止在此节点上调度任何吊舱。您可以看到这一点，并在需要时修改此行为。最佳实践是不要在主服务器上部署应用程序工作负载。

阅读有用的文章：主节点调度。

但是，您可以使用nodeSelector强制在主节点上部署吊舱/部署。例如，给主节点一个标签(比如dedicated=master )，并为您的吊舱设置nodeSelector以查找这个标签。

参见更多信息：主节点部署。