在上一篇文章中
K8S – 关于ClusterIP – 集群中服务之间的反向代理和负载均衡器
ClusterIP :主要特性介绍
k8s集群中代理的多实例服务
然而，ClusterIP 还有另一个变体：Headless Services。
用于代理集群外部的IP资源。
当然，代理外部资源的方式有很多种，包括无头服务和externalName等服务。
本文主要介绍无头服务
什么是无头服务
第：章
https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services
无头服务
在某些情况下，您可能不需要负载平衡或单独的服务IP。在这种情况下，您可以通过将集群IP (spec.clusterIP) 值显式设置为“None”来创建无头服务。
无头服务允许您与其他服务发现机制交互，而无需绑定到Kubernetes 实现。
Headless 服务不获取集群IP，kube-proxy 不处理此类服务，平台不提供负载均衡或路由支持。
无头服务允许客户端直接连接到他们想要的任何Pod。 无头服务不使用虚拟IP 地址和代理来配置路由和数据包转发。相反，无头服务通过集群DNS 服务提供的内部DNS 记录报告每个Pod 的端点IP 地址。 这些DNS 记录由集群的内部DNS 服务提供。要定义无头服务，必须将.spec.type 设置为ClusterIP（这也是type 的默认值）并将.spec.clusterIP 设置为None。
字符串值None 是一种特殊情况，与不设置.spec.clusterIP 字段不同。
DNS 如何自动配置取决于服务是否定义了选择器。
其实官方文档说的不是很清楚，还是需要一些练习才能理解。
ClusterIP, headless 和 externalName的区别
这三个都属于k8s的服务范畴
另外，headless 是一种ClusterIP，一种特殊的ClusterIP（属性spec.clusterip=none）。
另外，externalName 专门用作外部资源代理。
为什么本文中的示例不使用externalName 服务？
原因是externalName有局限性，只能代理外部资源的域名，不能代理IP地址。
以下是来自官网的描述
https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#externalname
=========================================
ExternalName 类型
InitialName 类型的服务将服务映射到DNS 名称，而不是常见的选择器（例如my-service 或cassandra）。可以使用spec.externalName参数指定这些服务。
例如，以下服务定义将prod 命名空间中的my-service 服务映射到my.database.example.com。
api版本： v1
kind:服务
元数据：
name: 我的服务
命名空间：产品
规格：
type: 外部名称
externalName: my.database.example.com
为了显示：
类型为：ExternalName 的服务接受IPv4 地址字符串，但将该字符串视为数字DNS 名称而不是IP 地址（尽管此类名称在Internet 上的DNS 中不可用）。 DNS 服务器无法解析类似于IPv4 地址的外部名称。
如果您想将服务直接映射到特定IP 地址，请考虑使用无头服务。
========================================================================
考虑到本文中的示例使用IP 地址，我们不会详细讨论externalName。
应用场景
如上所示，我们需要找到一种解决方案，让集群外的云用户可以访问bq API 服务的实例。
方法一：
将云用户IP 硬编码添加到bq-api-service 配置文件中。
坏处：
难以实现负载均衡
如果您将云用户部署到其他服务器，则需要进行配置更改
方法二：
这是本文中使用无头服务代理集群外部资源的示例。
创建和应用headless service
编写yaml
无头云用户
api版本： v1
kind:服务
元数据：
name: 无头云用户
命名空间： 的默认值
标签:
app: 云用户
规格：
集群IP: 无# 无头服务
—
api版本： v1
kind: 端点
元数据：
name: headless-cloud-user #名称必须与服务名称相同
# 服务将使用此端点来获取目标IP和端口
命名空间： 的默认值
标签:
target-app: 云用户
子集：
– 地址：
-ip: 192.168.0.47
– ip: 192.168.0.51 # 可以添加更多IP并支持基本负载均衡
我已经掉进陷阱了
首先，服务部分不能写spec.selector，因为服务部分和端点部分需要分开编写。想想看，这个服务不是代理Pod 资源，所以它不需要有选择器。
clusterIP 设置为0。我尝试了一下，但没有实际编写此配置，它被分配了一个IP，但服务本身仍在工作。
Service中不需要写入端口信息。例如，如果调用端口8080，则映射将是外部资源的相同端口。
在端点部分，名称必须与服务的名称相同。 否则它不会工作
标签不必相同，如示例中所示
可以写多个代理IP
部署yaml
[gateman@manjaro-x13 bq-api-service-proxy-external]$ kubectl apply -f headless-cloud-user.yaml
服务/无头云- 用户创建
端点/无头云- 用户创建
查看服务：
[gateman@manjaro-x13 bq-api-service-proxy-external]$ kubectl get svc -o Wide
名称类型集群IP 外部IP 端口期限选择器
headless-cloud-user ClusterIP 无无无56m 无
kubernetes ClusterIP 10.96.0.1 无443/TCP 78d 无
您可以看到该服务仍然属于ClusterIP，但即使没有分配虚拟IP，CLUSTER-IP 列现在也是吉祥的。
显示端点。
[gateman@manjaro-x13 bq-api-service-proxy-external]$ kubectl get ep -o Wide
名称端点年龄
无头云用户192.168.0.47,192.168.0.51 57m
库伯内特192.168.0.3:6443 78d
代理两个外部IP，但没有端口信息。实际上你可以代理任何端口。
测试
当然，最快的测试方法是在dns-test容器中进行测试。
正如您所看到的，当多次调用此服务时，会从具有不同IP 地址的实例中随机返回信息。
当我关闭其中一个IP 实例时，
多次调用后，会自动选择健康的实例。这很棒。
/#curlheadlesscloud-user:8081/actuator/info
{\’app\’:\’云用户API\’,\’版本\’:\’1.0.1\’,\’主机名\’:\’b1a26a0f6685\’,\’dbUrl\’:\’jdbc:mysql: //192.168.0.42:3306/demo_cloud_user?useUnicode=truecharacter Encoding=utf – 8useSSL=falseallowPublicKeyRetrieval=true\’，\’des/#curl headless-cloud-user:8081/actuator/info
{\’app\’:\’云用户API\’，\’版本\’:\’1.0.1\’，\’主机名\’:\’e166316cddb1\’，\’dbUrl\’:\’jdbc:mysql://192.168.0.42:3306/demo_cloud_user?useUnicode=truecharacterEn编码=utf- 8useSSL=falseallowPublicKeyRetrieval=true\’，\’des/#curl headless-cloud-user:8081/actuator/info
{\’app\’:\’云用户API\’，\’版本\’:\’1.0.1\’，\’主机名\’:\’e166316cddb1\’，\’dbUrl\’:\’jdbc:mysql://192.168.0.42:3306/demo_cloud_user?useUnicode=truecharacterEn编码=utf- 8useSSL=falseallowPublicKeyRetrieval=true\’，\’des/#curl headless-cloud-user:8081/actuator/info
{\’app\’:\’云用户API\’，\’版本\’:\’1.0.1\’，\’主机名\’:\’e166316cddb1\’，\’dbUrl\’:\’jdbc:mysql://192.168.0.42:3306/demo_cloud_user?useUnicode=truecharacterEn编码=utf- 8useSSL=falseallowPublicKeyRetrieval=true\’，\’des/#curl headless-cloud-user:8081/actuator/info
{\’app\’:\’云用户API\’,\’版本\’:\’1.0.1\’,\’主机名\’:\’b1a26a0f6685\’,\’dbUrl\’:\’jdbc:mysql: //192.168.0.42:3306/demo_cloud_user?useUnicode=truecharacter Encoding=utf – 8useSSL=falseallowPublicKeyRetrieval=true\’，\’des/#curl headless-cloud-user:8081/actuator/info
一些见解
我看到了这个例子并提出了一些评论。
由于headless可以代理外部资源，而headless也属于ClusterIP，所以认为ClusterIP只能代理内部资源是错误的。
认为无头服务没有负载均衡的想法是错误的，因为无头服务可以写入多个IP地址，因此具有基本的负载均衡能力。
以上关于#K8S的相关内容来源仅供参考。相关信息请参见官方公告。
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/91869.html
