Kubernetes--深入理解Service与CoreDNS

文章目录

Service功能
- - Service 的常见使用场景
- Service的模式
- - iptables
  - IPVS
- Service类型
- - ClusterIP
  - NodePort
  - LoadBalancer
  - ExternalName
- Service的工作机制
- Endpoint
- - Endpoint 与 Service 的关系
  - Endpoint 的工作原理
  - 命令操作
CoreDNS
- CoreDNS 的配置
- CoreDNS 的典型插件
- Corefile 示例
- CoreDNS 的工作原理
- 举例说明

Service功能

在 Kubernetes中，Service是用于将一组Pod以稳定的网络接口暴露出来，公开为一个网络服务的抽象，提供稳定的访问入口。虽然 Pod 的 IP 是动态分配的、会频繁变动，但 Service 通过分配一个固定的虚拟 IP（ClusterIP）来解决 Pod 动态变化的问题，并实现负载均衡，确保客户端始终可以通过统一的方式访问服务。

Service功能：
  1.服务发现
      发现一组提供了相同服务的 Pod：标签选择器，在同一 namespace 中筛选符合的条件的Pod；
      实际上并非由 Service 资源自己完成，而是借助于另一种称为 Endpoints/EndpointSlice 完成的； 
      集群内的 Pod 可以通过 Service 名称进行通信，Kubernetes 会自动管理这些名称解析。
    由标签选择器实现
    
  2.负载均衡
      Service作为流量入口和负载均衡器，其入口为ClusterIP：这组筛选出的Pod的IP地址，将作为该Service的后端服务器； 
      Service会将访问请求均匀地分发给后端的多个 Pod，默认使用轮询方式进行负载均衡。
    由iptables/ipvs实现
      
  3.名称解析
      为该组Pod所代表的服务提供一个名称：依赖于Cluster DNS，对于每个Service，自动生成一个A、PTR和SRV记录
    由DNS实现

在这里插入图片描述

Service 的常见使用场景

Service 的常见使用场景：
  1.前端访问后端服务：一个 Web 前端可能通过 Service 访问后端的多个服务实例。
  2.微服务架构：Service 是微服务架构中的核心组件，用于不同服务之间的通信。
  3.服务发现：通过 DNS 或环境变量等方式，Pod 可以发现并访问其他 Pod 提供的服务。

Service的模式

在 Kubernetes 中，Pod的生命周期是短暂的，可能会被终止和重新创建，而 Service 提供了一个持久的访问入口，确保用户或其他服务可以通过固定的 IP 地址或 DNS 名称访问这些 Pod。Kubernetes 中的 Service 支持多种模式，每种模式决定了 Service 如何路由流量到 Pod，以及如何处理集群内外的网络请求。

Kubernetes的Service提供了多种模式来应对不同的网络通信需求：
  1.iptables模式：
      当前最常见的默认模式，性能较好，适用于大多数场景。
      
  2.IPVS模式：
      高性能负载均衡模式，适合大规模、高并发的场景，提供更多的负载均衡算法。

iptables

iptables 模式是 Kubernetes 的默认模式，也是当前最常用的 Service 模式。它使用 Linux 内核中的 iptables 来完成流量的路由和转发。

iptables模式工作机制：
  1.kube-proxy运行时会为每个Service创建一条 iptables 规则。
  2.这些规则被放入内核中，并在内核层执行流量转发，而不需要经过用户空间。
  3.内核根据这些规则直接在Pod之间转发流量，实现负载均衡。

特点：
  1.性能更高，因为流量转发完全在内核中完成，不需要用户空间的参与。
  2.延迟低，处理能力强，适合大规模生产环境。
  3.当Pod或Service更新时，kube-proxy动态更新iptables规则。

示例：当有一个 Service my-service，该 Service 选择了多个 Pod，iptables 会创建一个规则集，确保请求可以分发到与这个 Service 相关联的 Pod。流量在 Pod 之间均匀分配。

IPVS

IPVS (IP Virtual Server) 是一种基于内核的负载均衡技术，使用 Linux 虚拟服务器技术（通过 ipvsadm 管理），是 iptables 模式的增强版。IPVS 模式是 Kubernetes 中最新引入的一种 Service 模式，提供了更强的扩展性和性能。

IPVS模式工作机制：
  1.与iptables类似，kube-proxy监控集群中Service和Pod的变化，但它使用 IPVS 进行流量的路由和负载均衡。
  2.IPVS 在内核空间中实现，通过内核模块提供负载均衡功能。
  3.IPVS 支持更多的负载均衡算法，例如轮询（round-robin）、最小连接数、源地址哈希等。

特点：
  1.IPVS比iptables性能更高，能够更快地处理大量规则和服务。
  2.IPVS支持更多的负载均衡算法，灵活性更强。
  3.更适合大规模高并发的服务。

优点：
  1.具有比iptables更高的吞吐量和更低的延迟。
  2.支持动态的服务更新，处理大规模流量的能力较强

Service类型

在 Kubernetes 中，Service 有不同的类型，适用于不同的访问需求。常见的 Service 类型包括：ClusterIP、NodePort、LoadBalancer 和 ExternalName。

常见的 Service 类型
  1.ClusterIP 是最常见的服务类型，适合集群内部的通信。
  
  2.NodePort 允许外部客户端通过节点的 IP 和端口访问集群中的服务。
  
  3.LoadBalancer 为云环境中的 Kubernetes 集群提供外部负载均衡，适用于需要在互联网上提供服务的应用。
  
  4.ExternalName 服务重定向 DNS 名称，用于 Kubernetes 内部服务访问外部 DNS 名称服务。

在这里插入图片描述

ClusterIP

集群内部使用，东西流量

ClusterIP
  Client --> Service_IP:Service_Port --> Pod_IP:Pod_Port 

  功能：
    这是默认的Service类型，服务只在集群内部暴露，其他集群内的Pod可以通过服务的ClusterIP进行访问。
  
  适用场景：
    只需要在集群内部访问的服务，例如微服务之间的通信。
  
  特点：
    Kubernetes自动分配一个虚拟IP（ClusterIP）作为访问入口。
    只能在集群内部访问，外部无法直接访问。

apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80       # 暴露的端口
      targetPort: 8080  # Pod 内部应用的端口
  type: ClusterIP

NodePort

NodePort
   Client --> Node_IP:NodePort --> Pod_IP:Pod_Port

功能：
  服务不仅在集群内部暴露，还通过每个节点上的一个固定端口在集群外部暴露。
  
适用场景：
  需要从外部访问集群中的服务，但没有使用外部负载均衡器的环境。

特点：
  Kubernetes 在每个节点上开放一个静态端口（范围 30000-32767）。
  可以通过节点的 IP 地址和指定的端口号从集群外部访问服务。

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80         # 服务内部端口
      targetPort: 8080  # Pod 内部的应用端口
      nodePort: 30007   # 固定节点上的外部端口

LoadBalancer

LoadBalancer
  Client --> LB_IP:LB_PORT --> Node_IP:NodePort --> Pod_IP:Pod_Port
  
  功能：
    在支持的云服务平台（如 AWS、GCP、Azure）上，创建一个外部负载均衡器，服务暴露在集群外部，
    外部客户端可以通过负载均衡器的IP进行访问。
  
  适用场景：
    需要在云环境下，提供一个能够自动扩展和负载均衡的外部服务。

  特点：
    Kubernetes 将为Service创建一个外部负载均衡器（如 AWS ELB），并将流量导入集群内部的Service。
    负载均衡器的 IP 地址是服务的外部访问入口。

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80         # 负载均衡器暴露的端口
      targetPort: 8080  # Pod 上实际服务的端口

ExternalName

ExternalName
  功能：
    将 Kubernetes 内部的 Service 名称映射到外部 DNS 名称，服务本身不创建ClusterIP，也无法通过内部IP访问。
  
  适用场景：
    集群内部的服务需要访问外部服务时。

  特点：
    将Service名称解析为一个外部的DNS名称，而不是一个内部的ClusterIP。
    不需要暴露端口，只是DNS名称的别名。

apiVersion: v1
kind: Service
metadata:
  name: my-external-service
spec:
  type: ExternalName
  externalName: example.com

在此例中，访问 my-external-service 时，会被重定向到 example.com，适用于在 Kubernetes 集群内访问外部服务的场景。

Service的工作机制

Service 的工作机制：
  1.标签选择器（Label Selector）：Service 通过标签选择器将服务与一组 Pod 关联起来。
    只要 Pod 的标签符合 Service 的选择器条件，这些 Pod 就会成为 Service 的后端。
    
  2.Endpoints：Service 维护一个 Endpoints 对象，记录了符合标签选择器的所有 Pod 的 IP 地址和端口。
    负载均衡时，Service 会将请求转发到 Endpoints 中的 Pod。

Endpoint

在 Kubernetes 中，Endpoint 是用来连接服务和实际提供服务的 Pod 的资源。Endpoint 对象负责维护一组 IP 地址和端口信息，这些信息指向在集群中运行的实际 Pod，使得客户端可以通过 Service 访问这些 Pod。

Endpoint概念
  1.Service：
      在Kubernetes中，Service 是一种抽象，用于定义一组 Pod 的访问策略。
      Service 通过 ClusterIPNodePort 或 LoadBalancer 等方式暴露应用程序，但它并不直接与 Pod 关联。
      
  2.Endpoint：
      Endpoint则是与 Service 相关联的资源，存储了与该服务相关联的实际 Pod 的 IP 地址和端口列表。
      当一个 Service 被创建时，Kubernetes 控制平面会自动生成与该 Service 对应的 Endpoint，
      用来维护服务和实际运行的 Pod 之间的映射。

Endpoint 与 Service 的关系

Endpoint 与 Service 的关系
  1.Service 是访问 Pod 的抽象层，Endpoint 是 Service 和 Pod 之间的桥梁。
  2.当一个 Service 选择了一组 Pod（通常是通过标签选择器），这些 Pod 的 IP 地址和端口会被加入到对应的 Endpoint 中。
  3.当客户端请求 Service 的 IP 和端口时，Service 会查找对应的 Endpoint 并将流量路由到 Endpoint 中定义的 Pod。

Endpoint 的工作原理

 Endpoint 的工作原理
  1.当创建一个Service时，Kubernetes会自动创建一个Endpoint对象，
    该对象包含符合该 Service 标签选择器（label selector）的所有Pod的IP和端口。
    
  2.Service 通过 ClusterIP（虚拟 IP）接收请求，查找与之对应的Endpoint，然后将流量发送到匹配的 Pod 中。

命令操作

查看 Service 相关的 Endpoint：

kubectl get endpoints <service-name>

查看 Endpoint 详细信息：

kubectl describe endpoints <service-name>

CoreDNS

CoreDNS 是 Kubernetes 中用于服务发现和内部 DNS 解析的默认 DNS 服务器。在 Kubernetes 集群中，Pod 之间相互通信、外部服务访问、以及服务的动态发现，都依赖于 DNS 解析，CoreDNS 扮演着关键角色。

CoreDNS的作用
  1.服务发现：
      Kubernetes使用DNS解析来帮助Pod找到集群中的服务。
      例如，通过service-name.namespace.svc.cluster.local可以解析到某个服务的ClusterIP。
      
  2.DNS解析：
      CoreDNS为集群内部的Pod和服务提供DNS服务，支持解析内部服务域名和外部域名（如访问互联网的域名）。
  
  3.可扩展和插件化：
      CoreDNS是模块化的，它通过不同的插件（如缓存、负载均衡、重定向等）来增强DNS功能，允许根据需要定制DNS行为。
  
  4.集群内网络通信的核心：
      Pod通过DNS解析服务IP来互相通信，确保了容器化应用在Kubernetes集群中的稳定运行。

CoreDNS 的配置

CoreDNS 的配置文件是一个 Corefile，定义了 DNS 的解析规则。这个配置文件位于 Kubernetes 集群的 ConfigMap 中，通常可以通过以下方式查看：

kubectl get configmap coredns -n kube-system -o yaml

CoreDNS 的典型插件

CoreDNS 是基于插件架构的，每个插件为 CoreDNS 增加了不同的功能。以下是一些常用的插件：

CoreDNS 的典型插件
  1.kubernetes：这是最关键的插件，负责处理 Kubernetes 内部服务的 DNS 解析。例如将 my-service.my-namespace.svc.cluster.local 解析为服务的 ClusterIP。
  2.forward：用于将无法在集群内解析的 DNS 查询转发到外部 DNS 服务器（如 8.8.8.8）。
  3.cache：对 DNS 查询结果进行缓存，以提高查询速度并减少对外部 DNS 服务器的请求。
  4.log：记录所有 DNS 请求的日志，方便调试和排查问题。
  5.hosts：允许使用本地 /etc/hosts 文件来解析固定的 IP 地址。

Corefile 示例

以下是一个典型的 Corefile 配置，它包括 kubernetes、forward、log 和 cache 插件。可使用kubectl describe命令查看Corefile 配置。

kubectl describe cm coredns -n kube-system

.:53 {
    errors
    log
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
    }
    forward . /etc/resolv.conf {
        max_concurrent 1000
    }
    cache 30
    reload
}

配置解读：
    .:53：表示 CoreDNS 监听 53 端口，处理所有 DNS 请求。
    errors：在出现错误时记录错误信息。
    log：记录所有 DNS 请求的日志，帮助调试。
    health：CoreDNS 会在健康检查时返回 HTTP 200 状态，表明它处于健康状态。
    kubernetes：负责处理 Kubernetes 内部 DNS 解析，将请求解析为集群内部的 Pod 和服务地址。
    forward：当 CoreDNS 无法解析请求时，它会将请求转发到外部 DNS 服务器（通常是集群节点的 /etc/resolv.conf 中指定的 DNS 服务器）。
    cache：缓存查询结果 30 秒，以减少对外部 DNS 服务器的请求负载。

在这里插入图片描述

CoreDNS 的工作原理

CoreDNS 的工作原理
  1.当一个 Pod 请求一个服务的 DNS 名称（例如 my-service.my-namespace.svc.cluster.local）时，DNS 请求会被 CoreDNS 处理。
  2.CoreDNS 检查 Corefile 中的配置，首先尝试使用 kubernetes 插件来解析请求。
  3.如果服务名存在，CoreDNS 将返回服务的 ClusterIP 地址。
  4.如果请求无法由 Kubernetes 内部解析，CoreDNS 使用 forward 插件将查询转发到外部 DNS 服务器进行解析。

举例说明

假设我们有一个服务 nginx-service，部署在命名空间 web 下，CoreDNS 将负责解析这个服务的 DNS 名称。

部署 nginx-service

首先，我们创建一个简单的 Nginx 服务：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  namespace: web
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

然后，创建 Nginx 的 Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.0
        ports:
        - containerPort: 80

使用 CoreDNS 进行服务解析
在集群中的其他 Pod 可以通过 DNS 访问 nginx-service：

curl http://nginx-service.web.svc.cluster.local

这个请求将由 CoreDNS 处理，CoreDNS 会使用 kubernetes 插件解析 nginx-service.web.svc.cluster.local，并返回 Nginx 服务的 ClusterIP。然后，Pod 可以通过这个 IP 访问 Nginx 服务。

总结
  1.CoreDNS 是 Kubernetes 集群内的默认 DNS 服务器，主要负责服务发现和 DNS 解析。
  2.它使用插件架构，通过 kubernetes 插件解析集群内服务，通过 forward 插件将外部域名请求转发到外部 DNS 服务器。
  3.配置文件 Corefile 决定了 CoreDNS 的行为，可以通过 ConfigMap 来进行配置和定制。
  4.CoreDNS 提供了丰富的插件支持，如缓存、日志记录等，帮助优化 DNS 查询的性能和调试体验。