KinD 是一个非常轻量级的 Kubernetes 安装工具，他将 Docker 容器当成 Kubernetes 的节点，使用非常方便。既然在 Docker 容器中可以运行 Kubernetes 集群，那么我们自然就会想到是否可以在 Pod 中来运行呢？在 Pod 中运行会遇到哪些问题呢？
KIND 当前依赖于 Docker（尽管他们计划很快支持其他容器运行时，例如podman）。因此，第一步是创建一个容器映像，该映像允许您在 Pod 内运行 Docker守护程序，以便使诸如docker run之类的命令在Pod内运行（又名 Docker-in-Docker 或 DIND ）。
Docker-in-Docker 是一个众所周知的问题，并且已经解决了相当一段时间。尽管如此，当尝试在生产 Kubernetes 集群中正确设置 Docker-in-Docker 时，我们仍然遇到很多问题。
为什么要写这样的一个工具呢？这是因为我司有多个 kubernetes 集群(8+)，且都是云托管服务无法接触到Apiserver配置，这就给我们带来一个痛点，开发、sre需要登录k8s dashbaord且不同部门和角色间需要不同的授权，原先都是通过 sa token 进行登录dashboard，但随着k8s集群的增长，每增加一个集群，就需要告知使用方对应dashboard访问地址以及对应的token，这不管是提供方还是使用方都让人感觉非常的痛苦。那是否有一款工具能提供统一地址统一登录多集群dashboard的方案呢？经过一番搜索后，发现并没有，市面上大多数是单集群集成 LDAP 的方案，主要是以 DEX 为主，但光单集群的统一登录授权方案就让人感觉非常的困难。难道就没有简单方便的工具供我们使用吗？好吧，那我就来打造这样一款工具吧。
Dashboard LDAP集成方案：
以上两篇文档是成LDAP的方案，个人感觉还不错，供有需要的人参考！
kube-scheduler 是 kubernetes 的核心组件之一，主要负责整个集群资源的调度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合理、更加充分的利用集群的资源，这也是我们选择使用 kubernetes 一个非常重要的理由。如果一门新的技术不能帮助企业节约成本、提供效率，我相信是很难推进的。
默认情况下，kube-scheduler 提供的默认调度器能够满足我们绝大多数的要求，我们前面和大家接触的示例也基本上用的默认的策略，都可以保证我们的 Pod 可以被分配到资源充足的节点上运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行特定类型的应用，这就需要我们的调度器能够可控。
kube-scheduler 的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监听 API Server，获取到 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创建一个 binding。
拓扑域: 表示在集群中的某一类 “地方”，比如某节点、某机架、某可用区或某地域等，这些都可以作为某种拓扑域。endpoint: k8s 某个服务的某个 ip+port，通常是 pod 的 ip+port。service: k8s 的 service 资源(服务)，关联一组 endpoint ，访问 service 会被转发到关联的某个 endpoint 上。拓扑感知服务路由，此特性最初由杜军大佬提出并设计。为什么要设计此特性呢？想象一下，k8s 集群节点分布在不同的地方，service 对应的 endpoints 分布在不同节点，传统转发策略会对所有 endpoint 做负载均衡，通常会等概率转发，当访问 service 时，流量就可能被分散打到这些不同的地方。虽然 service 转发做了负载均衡，但如果 endpoint 距离比较远，流量转发过去网络时延就相对比较高，会影响网络性能，在某些情况下甚至还可能会付出额外的流量费用。要是如能实现 service 就近转发 endpoint，是不是就可以实现降低网络时延，提升网络性能了呢？是的！这也正是该特性所提出的目的和意义。
之前在解决 CoreDNS 的5秒超时问题的时候，除了通过 dnsConfig 去强制使用 tcp 方式解析之外，我们提到过使用 NodeLocal DNSCache 来解决这个问题。NodeLocal DNSCache 通过在集群节点上运行一个 DaemonSet 来提高 clusterDNS 性能和可靠性。处于 ClusterFirst 的 DNS 模式下的 Pod 可以连接到 kube-dns 的 serviceIP 进行 DNS 查询。通过 kube-proxy 组件添加的 iptables 规则将其转换为 CoreDNS 端点。通过在每个集群节点上运行 DNS 缓存，NodeLocal DNSCache 可以缩短 DNS 查找的延迟时间、使 DNS 查找时间更加一致，以及减少发送到 kube-dns 的 DNS 查询次数。
在集群中运行 NodeLocal DNSCache 有如下几个好处：
conntrack 竞争并避免 UDP DNS 条目填满 conntrack 表（常见的5s超时问题就是这个原因造成的）