K8S-使用SVC域名解决ip不固定导致consul服务注册脏数据异常问题

1 概述

各个模块注册nacos时，采用svc域名的方式，各模块间feign调用时使用的svc 域名来访问，这样就可以和ip解耦。

否则如果使用不固定IP，则可能在重启的时候，导致consul里面有一堆脏节点数据，影响服务调用。

2 SVC域名

2.1 简介

SVC域名在Kubernetes（K8s）中是一个重要的概念，用于标识Service的名称，通常是由一个或多个DNS标签组成的。以下是关于SVC域名的详细解释：

2.2 SVC域名的格式

SVC域名的格式通常为“service-name.namespace-name.svc.cluster.local”。

• 其中，“service-name”是Service的名称，
• “namespace-name”是Service所在的命名空间的名称，
• “svc”是Kubernetes中预定义的DNS前缀，表示这是一个Service，
• “cluster.local”则是集群的域名。

2.3 SVC域名的作用

• 服务发现
  SVC域名可以将服务名称和Pod IP地址关联起来，使得其他Pod可以通过SVC域名来访问该服务。当一个Pod需要使用另一个服务时，它可以通过SVC域名来查找该服务的IP地址和端口号，从而建立与服务之间的通信。
• 负载均衡
  当一个Pod需要访问多个实例的同一个服务时，SVC域名可以用于负载均衡。Kubernetes会根据Service的配置和策略，将请求分发到不同的Pod上，以实现负载均衡。
• SVC域名的应用
  SVC域名在Kubernetes中的应用非常广泛，除了上述的服务发现和负载均衡外，还可以用于Ingress、ExternalName Service等场景。例如，通过Ingress和SVC域名的结合，可以实现外部流量到集群内部服务的路由和转发；而ExternalName Service则可以将集群内部的服务与外部服务进行关联，实现服务的透明化访问。

2.4 SVC域名的创建和管理

在Kubernetes中，SVC域名是通过创建Service资源来自动生成的。当创建一个Service时，Kubernetes会根据Service的元数据和配置信息，自动生成一个SVC域名，并将其与Service进行关联。

同时，Kubernetes还提供了DNS服务，用于解析SVC域名并返回对应的Pod IP地址和端口号。

2.5 总结

总之，SVC域名是Kubernetes中用于标识Service的重要概念，它通过将服务名称和Pod IP地址关联起来，实现了服务发现和负载均衡等功能，为Kubernetes集群的运维和管理提供了便利。

3 无状态服务

3.1 定义

在Kubernetes（K8s）中，无状态服务（Stateless Services）可以理解为一种不依赖于本地存储状态的服务。以下是关于K8s无状态服务的最通俗理解方式，遵循您要求的清晰格式：

无状态服务是指那些不保存任何有关请求或上下文的状态的服务。这意味着对于每一个请求，无状态服务都会以相同的方式处理，并且不依赖于任何先前的请求或状态。

3.2 特点

• 无依赖
  无状态服务的任何一个实例都可以处理来自客户端的请求，而请求之间没有关联。
• 水平扩展性
  无状态服务可以很容易地进行水平扩展，因为每个请求都是独立的，并且服务实例之间没有数据依赖。这意味着可以通过添加更多的副本来处理更多的请求流量。
• 状态无关
  无状态服务不会在本地存储持久化数据。多个服务实例对于同一个用户请求的响应结果是完全一致的。
• 可替换性
  无状态服务的实例可以随意启动和停止，而不会影响应用程序的状态或数据。

3.3 示例

无状态服务的典型示例包括：

• Web服务器：如Nginx、Apache等，它们处理HTTP请求，但不保存任何关于特定用户的会话或状态信息。
• API服务：提供RESTful API的服务，如各种微服务应用中的后端服务。
• 负载均衡器：如HAProxy、Nginx作为负载均衡器使用时，它们将请求分发到后端服务器，但不保存关于请求的状态。

3.4 部署方式

在Kubernetes中，无状态服务通常使用Deployment进行部署。因为它们的实例可以随意启动和停止，所以使用Deployment可以很方便地管理这些服务实例的生命周期。

3.5 无状态服务的IP和域名变化

无状态服务的IP或域名在Kubernetes（K8s）中可以变化，但这种变化通常是由Kubernetes内部机制自动管理，而不是由用户直接修改。以下是关于无状态服务IP或域名变化的详细解释：

• IP地址的变化：
  在Kubernetes中，每个Pod都有一个唯一的IP地址，这个IP地址是由Kubernetes网络插件自动分配的。当Pod被重新调度、重启或删除并重新创建时，它的IP地址可能会发生变化。

  对于无状态服务来说，由于它不依赖于特定的Pod IP地址，因此即使Pod IP地址发生变化，也不会影响服务的可用性和功能。服务消费者（如其他Pod）通常会通过Service来访问无状态服务，而不是直接通过Pod IP地址。

  Service在Kubernetes中负责暴露Pod的IP地址给其他服务进行访问。Service本身会有一个ClusterIP（集群内部IP），这个IP地址在Service的生命周期内是稳定的，即使Pod IP地址发生变化，ClusterIP也不会改变。

• 域名的变化：
  在Kubernetes中，Service通常与DNS条目相关联，这使得其他Pod可以通过Service的名称（即域名）来访问它。这个域名在Service的生命周期内是稳定的，并且不会因为Pod IP地址的变化而变化。

  然而，在某些情况下（如Service的重新创建或修改），Service的域名可能会发生变化。这通常发生在用户手动修改了Service的元数据（如name字段）时。但在大多数情况下，用户不会直接修改Service的域名，而是依赖于Kubernetes的自动管理。

• 总结：
  对于无状态服务来说，虽然Pod IP地址可能会发生变化，但由于Service的存在和Kubernetes的DNS机制，服务的稳定性和可用性并不会受到影响。服务消费者可以通过稳定的Service域名来访问无状态服务，而无需关心Pod IP地址的变化。

  如果需要修改无状态服务的访问方式（如更改端口、协议等），通常是通过修改Service的配置来实现的，而不是直接修改Pod IP地址或Service域名。这种修改可以通过kubectl命令或Kubernetes API来完成。

3.6 除了SVC以外其他实现无状态服务访问方式

除了SVC域名外，还有其他一些方式可以实现无状态服务的访问，但它们的稳定性和易用性可能不如SVC域名：

• 直接访问Pod IP
  虽然可以直接通过Pod的IP地址来访问无状态服务，但这种方式并不推荐。因为Pod的IP地址可能会因为多种原因（如Pod重启、迁移等）而发生变化，导致服务不可用。
• NodePort或LoadBalancer
  除了ClusterIP类型的Service外，Kubernetes还支持NodePort和LoadBalancer类型的Service。这些类型的Service会将服务暴露到集群外部，但它们的稳定性和易用性也取决于外部网络环境和负载均衡器的配置。
• NodePort
  通过在每个节点上打开一个特定的端口来暴露服务，但这种方式可能会受到节点数量和端口数量的限制。
• LoadBalancer
  依赖于云提供商提供的负载均衡器来暴露服务，这种方式可以提供更高的可用性和可扩展性，但通常需要额外的配置和管理成本。
• 自定义DNS解析
  可以在Kubernetes集群外部设置自定义的DNS服务器，将服务名称解析到对应的ClusterIP或NodePort。但这种方式需要额外的DNS服务器和配置管理，可能会增加复杂性和维护成本。
• 归纳
  在Kubernetes中，无状态服务的IP或域名变化通常不会影响使用，但推荐使用SVC域名来实现服务发现和访问。SVC域名提供了稳定性、服务发现和负载均衡等特性，使得无状态服务的访问变得更加简单和可靠。虽然还有其他一些实现方式，但它们的稳定性和易用性可能不如SVC域名。

3.7 总结

K8s无状态服务是一种不依赖于本地存储状态的服务，具有无依赖、水平扩展性、状态无关和可替换性等特点。它们通常使用Deployment进行部署，并且适用于不需要数据持久化的场景，如Web服务器、API服务和负载均衡器等。