Kubernetes 为 Service 和 Pod 创建 DNS 记录。 你可以使用一致的 DNS 名称而非 IP 地址访问 Service。
需要注意的是，修改操作系统的DNS缓存配置和管理可能需要管理员权限，且不同操作系统的配置方式可能有所不同。建议在进行相关操作前先查阅操作系统的相关文档或咨询系统管理员。
DNS 在 Kubernetes 集群中扮演着核心角色，它负责解析服务和 Pod 的名称，使得集群内的组件能够相互通信。如果 DNS 出现问题，可能导致服务间的通信失败，影响整个集群的稳定性和性能。
在 Kubernetes 中，比如服务 a 访问服务 b，对于同一个 Namespace下，可以直接在 pod 中，通过 curl b 来访问。对于跨 Namespace 的情况，服务名后边对应 Namespace即可。比如 curl b.default。那么，使用者这里边会有几个问题：
域名系统（DNS）是一种用于将各种类型的信息（例如IP地址）与易于记忆的名称相关联的系统。默认情况下，大多数Kubernetes群集会自动配置内部DNS服务，以便为服务发现提供轻量级机制。内置的服务发现使应用程序更容易在Kubernetes集群上相互查找和通信，即使在节点之间创建，删除和移动pod和服务时也是如此。
昨天发了一篇 Github 部署 | CDN 加速网页，速度嗖嗖的快！，之后觉得应该可以结束这一系列了。然而，评论里有人说我的网页访问不了：
K8S 部署reids 集群，nocos集群，rocketMQ 集群等需要理解的重要概念
域名系统（英语：Domain Name System，缩写：DNS）是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。
Kubernetes 服务发现是一个经常让我产生困惑的主题之一。本文分为两个部分：
上一篇文章中，我们详细介绍了 Kubernetes 中的作业副本控制器 Deployment：
DNS服务是域名系统的缩写， 英文全称：Domain Name System，将域名和IP地址相互映射。在容器环境中，DNS至关重要，例如在Kubernetes集群中，通常一组Pod由一个Service负载，但是Service的IP地址有可能需要变动，那么就可以让Pod通过域名的方式去访问Service，Pod无需理会IP地址的变化。
愈发复杂的应用程序正在依靠微服务来保持可扩展性和提升效率。Kubernetes为微服务提供了完美的环境，并能够让其与Kubernetes的工具组件和功能兼容。当应用程序的每个部分放置在一个容器中，整个系统就会更具可伸缩性。
深入了解支持服务间通信的 3 个原生 k8s 对象：ClusterIP Service、DNS 和 Kube-Proxy。
DNS 服务是 Kubernetes 内置的服务发现组件，它方便容器服务可以通过发布的唯一 App 名字找到对方的端口服务，再也不需要维护服务对应的 IP 关系。这个对传统企业内部的运维习惯也是有一些变革的。一般传统企业内部都会维护一套 CMDB 系统，专门来维护服务器和 IP 地址的对应关系，方便规划管理好应用服务集群。当落地 K8s 集群之后，因为应用容器的 IP 生命周期短暂，通过 App 名字来识别服务其实对运维和开发都会更方便。所以本篇就是结合实际的需求场景给大家详细介绍 DNS 的使用实践。
Deployment并不能满足所有的应用场景，因为它默认对应用做了一个简化假设处理，认为一个应用的所有Pod是完全一样的，但往往在实际应用中，多个实例相互间是存在依赖关系的，比如：主从关系，主备关系，实例与数据之间的关系等。
在之前几篇文章的基础，（Centos7部署Kubernetes集群、基于kubernetes集群部署DashBoard、为Kubernetes集群部署本地镜像仓库），本文继续搭建Kubernete中的服务注册发现机制——SkyDNS.
CoreDNS 是一个 DNS 服务器。基于 Go 语言开发。由于其灵活性，可以在多种不同的环境中使用。CoreDNS 已在 Apache 2 许可证版本获得许可，并且完全开源。其已成为 Kubernetes 1.13 + 以后版本的默认 DNS 服务。如今，当我们使用托管 Kubernetes 集群或为应用程序工作负载自行管理集群时，通常只需要关注应用程序本身，而无须过多关注 Kubernetes 提供的服务或如何利用它们。DNS 解析是任何应用程序的基本要求，因此我们需要确保它正常工作。
本文的将不深入探讨 coreDNS，而是解释 DNS 如何在 Kubernetes 中工作，coreDNS 包含什么以及 Corefile 如何使用插件。
为什么我在还没有开始讲解Service之前就要拿出来headless Service说一说呢？ 因为我自己在回顾知识的时候发现自己并没有想象中的那么懂 Headless Service这个机制。 今天自己再温故学习的同时 输出文档开源供大家公共学习
在k8s集群，我们通常通过 svc 做负载均衡来访问背后的 pod 实体，如果需要直接访问 pod 除了直接通过 pod IP 的方式还有什么方法呢？
PS：通过dns可以访问同一个namespace，dns跟网络经常使用的域名方式很类似的，就是域名dns找到对应的服务，性质是一样的。下节咱们说说如果不在同一个namespace下如何进行通信的问题。
Kubernetes Headless Service是Kubernetes中一种特殊类型的服务，与普通服务（ClusterIP和NodePort）不同，它不为Pod提供负载均衡和网络代理服务。相反，Headless Service将请求直接转发给后端Pod，因此它可以用于一些特殊的场景，例如有状态应用的服务发现和负载均衡。
客户反馈从pod中访问服务时，总是有些请求的响应时延会达到5秒。正常的响应只需要毫秒级别的时延。
kubernetes 提供了 service 的概念可以通过 VIP 访问 pod 提供的服务，但是在使用的时候还有一个问题：怎么知道某个应用的 VIP？比如我们有两个应用，一个 app，一个 是 db，每个应用使用 rc 进行管理，并通过 service 暴露出端口提供服务。app 需要连接到 db 应用，我们只知道 db 应用的名称，但是并不知道它的 VIP 地址。
在Linux 系统上，当一个应用通过域名连接远端主机时，DNS 解析会通过系统调用来进行，比如 getaddrinfo()。和任何Linux 操作系统一样，Pod 的 DNS 定义在 resolv.conf 文件中，其示例如下：
当前，云原生生态已经成为全球各大厂商以及企业尤其是互联网企业技术选型、场景推广的一个重要参考标准。云原生所代表的技术已经逐渐成为大家的共识，从一个虚无缥缈的概念逐渐演化成众多参与者的下一个技术战略储备。自然而言，承载业务需求的应用架构就会提及到微服务生态体系，以及其中最重要的分布式协作模式——“Service Discovery”，即：服务发现。
TKE集群中使用的DNS解析是采用coreDNS，Kubernetes 1.11 和更高版本中，CoreDNS 位于 GA 并且默认情况下与 kubeadm 一起安装
每个 Kubernetes 服务都会自动注册到集群 DNS 之中。注册过程大致如下：
从Kubernetes 1.11开始，可使用CoreDNS作为Kubernetes的DNS插件进入GA状态，Kubernetes推荐使用CoreDNS作为集群内的DNS服务。 我们先看一下Kubernetes DNS服务的发展历程。
问题描述：查看pod日志报错，Normal Killing 39s (x735 over 15h) kubelet, 10.179.80.31 Killing container with id docker://apigateway:Need to kill Pod，可能是磁盘满了，无法创建和删除 pod
首先，StatefulSet 的控制器直接管理的是 Pod。这是因为，StatefulSet 里的不同 Pod 实例，不再像 ReplicaSet 中那样都是完全一样的，而是有了细微区别的。比如，每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式，就是通过在 Pod 的名字里加上事先约定好的编号。
Headless Service是Kubernetes中一种服务发现机制，它可以为有状态应用程序提供服务发现和负载均衡，与ClusterIP Service和NodePort Service不同，Headless Service的DNS名称返回的是后端Pod的IP地址，而不是一个集群IP地址。
服务发现就是一种提供服务发布和查找的服务，是基于服务架构（SOA）的核心服务，需具备以下关键特性：
作为一个后端工程师，因为负责的大部分项目都是Web服务这类的“无状态应用”，在平时工作中接触到的最常用的Kubernetes控制器是Deployment，但是Deployment只适合于编排“无状态应用”，它会假设一个应用的所有 Pod是完全一样的，互相之间也没有顺序依赖，也无所谓运行在哪台宿主机上。正因为每个Pod都一样，在需要的时候可以水平扩/缩，增加和删除Pod。
在 Kubernetes 集群中，通常是先通过 NodeLocal DNS Cache 进行域名解析，如果 NodeLocal DNS Cache 没有找到对应的域名解析结果，才会向 CoreDNS 发起请求。在部署层面上看nodelocaldns会在每个节点上运行一个 DNS 缓存服务，而CoreDNS则不需要每个k8s节点上都部署一个，可以根据需求设置CoreDNS服务数量。
Kubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然后一旦被销毁生命就永远结束。通过ReplicationController 能够动态地创建和销毁Pod（列如，需要进行扩缩容，或者执行滚动升级）；每个Pod都会获取它自己的IP地址，即使这些IP地址不总是稳定可依赖的。这会导致一个问题；在Kubernetes集群中，如果一组Pod（称为backend）为其他Pod（称为frontend）提供服务，那么哪些frontend该如何发现，并连接到这组Pod中的那些backend呢？
k8s最基础的调度单位是pod；当一个pod异常退出的时候会重新创建另一个pod，但是这个时候pod的ip就改变了，所以我们不能直接使用pod-ip来访问其他的pod。
之前在解决 CoreDNS 的5秒超时问题的时候，除了通过 dnsConfig 去强制使用 tcp 方式解析之外，我们提到过使用 NodeLocalDNSCache 来解决这个问题。NodeLocalDNSCache 通过在集群节点上运行一个 DaemonSet 来提高 clusterDNS 性能和可靠性。处于 ClusterFirst 的 DNS 模式下的 Pod 可以连接到 kube-dns 的 serviceIP 进行 DNS 查询。通过 kube-proxy 组件添加的 iptables 规则将其转换为 CoreDNS 端点。通过在每个集群节点上运行 DNS 缓存，NodeLocal DNSCache 可以缩短 DNS 查找的延迟时间、使 DNS 查找时间更加一致，以及减少发送到 kube-dns 的 DNS 查询次数。
在静态pod目录下创建yaml，使用下面命令生成符合要求的myservice.yaml，等待kubelet自动拉起静态pod
1、部署Cluster DNS 1.1 原理:(看看吧，摘抄网上的↓) 通过前面对Kubernetes的讨论（Kubernetes核心概念总结）．我们已经知道，每个Kubernetes service都绑定了一个虚拟IP 地址（ClusterIP），而且Kubernetes最初使用向pod中注入环境变量的方式实现服务发现，但这会带来环境变量泛滥等问题。故需要增加集群DNS服务为每个service映射一个域名。到Kubernetes v1.2版本时，DNS作为一个系统可选插件集成到Kubernetes集群中。
Service 是 k8s 网络部分的核心概念，在 k8s 中，Service 主要担任了四层负载均衡的职责。本文从负载均衡、外网访问、DNS 服务的搭建及 Ingress 七层路由机制等方面，讲解 k8s 的网络相关原理。
Kubernetes的Service是一种逻辑抽象，用于访问一个或多个Pod。它为一组Pod提供了一个稳定的IP地址和DNS名称，以便其他应用程序或用户可以访问它们。Service允许Pod动态添加或删除，而不会影响服务的可用性。Service还支持负载均衡，可以将请求分配给多个Pod以提高可扩展性和可靠性。
服务发现是 K8s 的一项很重要的功能。K8s 的服务发现有两种方式，一种是将 svc 的 ClusterIP 以环境变量的方式注入到 pod 中；一种就是 DNS，从 1.13 版本开始，coreDNS 就取代了 kube dns 成为了内置的 DNS 服务器。这篇文章就来简单分析一下 coreDNS。
可以看到与deployment不同，statefulset中的每个pod都分配到了独立的pv，且重启pod后存储对应关系不变
在学习StatefulSet之前， 我们先看下什么是有状态应用， 什么是无状态应用。
作为服务发现机制的基本功能，在集群内需要能够通过服务名对服务进行访问，这就需要一个集群范围内的DNS服务来完成从服务名到ClusterIP的解析。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
