k8s的service资源类型有ClusterIP、Nodeport、ExternalName、LoadBalancer、Headless(None)

这篇具有很好参考价值的文章主要介绍了k8s的service资源类型有ClusterIP、Nodeport、ExternalName、LoadBalancer、Headless(None)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1. ClusterIP

是什么


ClusterIP 是在所有节点内生成一个虚拟IP,为一组pod提供统一的接入点,当service存在时,它的IP地址和端口不会发生改变,客户端通过service的ip和端口建立连接,由service将连接路由到该服务的任意一个后端pod上,通过这种方式,客户端不需要知道每个pod的具体ip,pod可以随时移除或创建,同时实现pod间的负载均衡。

Service通过使用标签选择器来指定哪些pod属于同一组。

创建service:

clusterip nodeport,kubernetes,java,docker

注意:

Port : 80 为Service 服务端口,  targetPort:8080 为POD中的容器内部端口, 一般情况下保持一致!

新的服务会分配一个集群内部IP,只能在集群内部访问,服务的主要目标是使集群内其他pod可以访问当前这种service 服务的pod,但通常也希望对外暴露服务,如何对外暴露,在文章后面有讲解

clusterip nodeport,kubernetes,java,docker

集群内部服务流转:

clusterip nodeport,kubernetes,java,docker

配置服务的会话亲和性


同一个客户端向一组pod的服务发起请求,服务每次将请求转发给不同的pod,如果希望特定的客户端产生的所有请求都指向同一个pod,可以设置服务的sessionAffinity属性为ClientIP(而不是None,None是默认值)

clusterip nodeport,kubernetes,java,docker

这种方式会将来自同一个clientIP的所有请求转发至同一个pod。

k8s仅支持None和ClinetIP两种会话亲和性配置,不支持基于cooki的会话亲和性选项,因为k8s的service不是在http层面工作,服务处理TCP和UDP包,cookie是HTTP协议的内容,所以service并不知道cookie。

同一个服务可以暴露多个端口,暴露多个端口必须为端口指定名字。

服务发现方式


客户端pod如何知道服务的IP和端口?有两种方式

1. 通过环境变量

当创建一个新pod时,k8s会初始化一系列环境变量给容器,其中包含当前存在的所有服务IP和端口,在任意一个pod容器中执行env命令,可以看到

clusterip nodeport,kubernetes,java,docker

 如上图所示,包含一个叫kubia的服务的地址和端口

2. 通过DNS发现服务(跨VPC 服务访问:coreDNS 解析

k8s的kube-system命名空间下有一个自带的dns服务组件kube-dns,集群中的所有pod都使用它作为dns,在每个容器的/etc/resolv.conf中有配置,所有pod中的进程dns查询都会被这个dns服务器响应,这个服务器知道集群中运行的所有服务。

(pod是否使用内部的dns服务器是根据pod中spec的dnsPolicy属性决定的)

客户端在知道服务名的前提下可以通过全限定域名(FQDN)来访问服务,格式为

{servicename}.{namespace}.svc.cluster.local

例如一个backend服务在default命名空间下,其域名为backend.default.svc,cluster.local,如果是在同一个命名空间下,可以省略命名空间及后面的部分

注意:直接ping service Ip是不通的,这是因为服务的集群IP是一个虚拟IP,并且只有与端口结合时才有意义。

DNS 解析文件/etc/resolv.conf 

配置domain域: 声明主机的域名,当查询不完全的域名时主机名将被使用(相当于search的默认值)

配置search域:调整/etc/resolv.conf配置文件,添加search,会顺序补全,直到有响应

clusterip nodeport,kubernetes,java,docker

 2. 就绪探针(readinessProbe)


我们已经知道pod的标签和服务选择器一样时,pod就会作为服务的后端,但是存在一种情况,pod刚启动时还没有加载好配置,或者需要执行预热防止第一个请求时间过长,这时不想让该pod接收请求。

方案是实用就绪探测器,k8s定期向pod执行探测,发现探测结果成功了才将服务转发过去。

就绪探针有三种类型

Exec探针 :在容器内执行进程,根据进程退出码决定

HTTP GET探针: 向容器发送http get请求,根据返回码决定

TCP socket探针 :向容器指定端口打开TCP连接,如果连接成功,判定为就绪

启动容器后会定期向容器执行探针操作,如果pod报告为尚未就绪,则会从对应的服务中剔除该pod,等下次探测成功后,再将pod添加到endpoints

clusterip nodeport,kubernetes,java,docker

3. headless (无头服务一般用户集群内部访问)


创建服务时默认会生成一个集群IP,客户端无需知道后面有几个pod,但是如果需要具体每一个pod 的IP呢,只需要指定clusterIp为None即可,即headless,headless类型的区别就是不会为服务生成虚拟IP

clusterip nodeport,kubernetes,java,docker

 常规的服务通过DNS服务器获得servicename.namespace.svc.cluster.local的是集群IP,而headless服务获取该域名的实际IP是所有后台pod的IP列表。

从客户端角度来看headless与常规服务并无不同,但是对于headless服务,由于DNS返回了pod的IP,客户端直接连接到pod,而不是通过服务代理。

headless仍然提供跨pod负载均衡,但是是通过DNS轮询机制不是通过服务代理。

连接集群外部服务的方式:手动配置Endpoint、使用ExternalName 为外部服务创建别名。


1. Endpoint


服务service和pod并不是直接相连的,它们之间有个Endpoint资源,Endpoint资源就是一组pod的ip地址和端口的列表,和其他k8s资源一样,可以通过kubectl get endpoints 查看信息。

在Service的spec中定义的pod选择器,不是由服务直接使用,而是用于构建IP和端口列表,然后存储在Endpoint资源中。

如果创建服务时不指定选择器,将不会创建Endpoints(没有选择器不知道服务该包含哪些pod),这样可以分别手动配置它们。

clusterip nodeport,kubernetes,java,docker

为没有选择器的服务创建Endpoint资源,注意Endpoint是一个独立的资源,并不是Service的属性,由于Service没指定选择器,所以需要手动创建Endpoint

clusterip nodeport,kubernetes,java,docker

 Endpoint对象需要与服务同样的名称,并包含目标IP地址和端口列表,这样服务就可以和有选择器一样正常使用了。将IP配置为外部服务,就可以连接外部服务了

clusterip nodeport,kubernetes,java,docker

2. ExternalName (跨VPC 外部服务访问)


创建外部服务的别名,创建service时指定type字段为ExternalName,例如有一个外部服务域名为api.somecompany.com

clusterip nodeport,kubernetes,java,docker

服务创建后可以通过external-service.defaul.svc.cluster.local 连接外部服务,ExternaleName服务仅在DNS级别实施,为服务创建了简单的CNAME DNS记录,因此,连接到服务的客户端将直接连接到外部服务,完全绕过服务代理。出于这个原因,这些类型的服务不会有集群IP.

CNAME 记录指向完全限定的域名而不是数字IP地址。

暴露服务的几种方式:Nodeport、LoadBalancer、Ingress↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

4. Nodeport


创建Servcie时指定type为Nodeport,会在所有集群节点上开一个相同的端口,创建Nodeport时的同时会创建ClusterIP,指定端口不是强制的,如果忽略,集群会自动分配一个

clusterip nodeport,kubernetes,java,docker

 在集群内部可以通过clusterip访问,集群外部通过节点IP:nodeport 访问。到达任何一个节点的连接将会被重定向到一个随机的pod,该pod不一定是位于接收节点的Pod.

clusterip nodeport,kubernetes,java,docker

 如果集群外部的客户端总是指向某个指定节点,那么当这个节点故障时将无法访问,因此节点前面需要一个负载均衡器,以保证发送的请求传播到健康的节点。

5. loadbalancer


负载均衡器

clusterip nodeport,kubernetes,java,docker

负载均衡器拥有一个可公开访问的IP地址,并将连接重定向到服务。需要注意的是 ,loadbalancer需要额外的基础设施支持,如果环境不支持,则不会调负责均衡器,该服务就像一个Nodeport服务一样了。

clusterip nodeport,kubernetes,java,docker

防止不必要的网络跳数
当外部客户端通过节点端口(包括使用负载均衡的情况),随机选择的pod不一定和接收连接在同一个节点,需要额外的网络跳转,可以在服务的sepc中设置亲和性为local避免这种情况

clusterip nodeport,kubernetes,java,docker

 弊端是这样必须要保证节点都有Pod,如果节点没有pod,连接会被挂起。同时会出现pod负载不均衡,如下图

clusterip nodeport,kubernetes,java,docker

获取客户端IP
在集群内访问服务时,服务端可以获取客户端地址,但是通过节点端口访问时,由于发生了源网络地址转换(SNAT),因此数据包的源IP地址发生了更改。使用上述的Local策略可以保留源IP,因为接收连接的节点和pod节点没有额外的跳跃(不执行SNAT)。

6. Ingress


上文介绍的LoadBalancer需要自己的负载均衡器,以及独有的公网IP地址,而Ingress只需要一个公网IP就能为许多服务提供访问。当客户端向Ingress发送http请求时,Ingress会根据请求的主机名和路径决定要发送的服务。

clusterip nodeport,kubernetes,java,docker

 Ingress在应用层工作,可以提供基于cookie的会话亲和性功能。

Ingress必需要Ingress控制器才能运行,不同的k8s环境使用不同的控制器实现,首先要确保环境启用了Ingress控制器。

clusterip nodeport,kubernetes,java,docker

clusterip nodeport,kubernetes,java,docker  

上图定义了一个单一规则的Ingress,Ingress控制器收到的请求主机kubia.example.com的请求会被发送到kubia-noport服务的80端口。

获取Ingress的IP地址:

clusterip nodeport,kubernetes,java,docker

 配置DNS服务器将kubia.example.com指向得到的IP,或者在客户端 /etc/hosts文件中配置。

clusterip nodeport,kubernetes,java,docker

将不同服务映射到同一主机名的不同路径下:

clusterip nodeport,kubernetes,java,docker

将不同服务映射到不同主机名下:

clusterip nodeport,kubernetes,java,docker

排除服务故障思路:


服务是k8s的重要概念,也是让许多开发感到困惑的根源。许多开发同学为了弄懂无法通过服务IP或FQDN连接到pod的原因花了大量时间。了解如何排序服务故障是有必要的,如果无法访问pod,排查如下:

首先, 确保从集群内连接到服务的集群IP,而不是从外部
不要通过ping服务IP 来判断服务是否可访问(请记住,服务的集群IP是虚拟IP, 是无法ping通的)。
如果已经定义了就绪探针, 请确保 它返回成功;否则该pod不会成为服务的一部分 。
要确认某个容器是服务的一部分, 请使用kubectl get endpoints来检查相应的端点对象。
如果尝试通过FQDN或其中一部分来访问服务(例如,myservice.mynamespace.svc.cluster.local或 myservice.mynamespace), 但
并不起作用, 请查看是否可以使用其集群IP而不是FQDN来访问服务 。
检查是否连接到服务公开的端口,而不是目标端口 。
尝试直接连接到podIP以确认pod正在接收正确端口上的 连接。
如果甚至无法通过pod的IP 访问应用, 请确保应用不是仅绑定 到本地主机。
 文章来源地址https://www.toymoban.com/news/detail-674311.html

到了这里,关于k8s的service资源类型有ClusterIP、Nodeport、ExternalName、LoadBalancer、Headless(None)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • (七)K8S核心资源Service

    Kubernetes(K8s)中的Service是一种抽象,用于定义一组Pod的访问方式和网络规则。它提供了一个稳定的网络终结点,使得应用程序能够通过Service名称来访问后端的Pod实例。 Service为一组具有相同功能的Pod提供了一个统一的入口,隐藏了Pod背后的具体细节。通过Service,应用程序可

    2024年02月06日
    浏览(33)
  • k8s~ExternalName的使用

    在Kubernetes中, Service 资源的 type 字段有多种选项,其中之一是 ExternalName 。 ExternalName 类型的服务用于将外部服务引入到Kubernetes集群中,通常会将外部服务的域名映射到Kubernetes集群中的一个DNS名称。 ExternalName 服务类型不涉及端口映射或负载均衡。它只是一个DNS别名,将Kub

    2024年02月08日
    浏览(37)
  • 11-k8s中网络资源service

            每当我们企业的业务pod迭代功能的时候,都会修改pod,修改后重新启动pod,ip就会变化,那么在生产环境当中,从用户到宿主机、从宿主机到pod,这一个访问流程,都是事先写好的,一旦pod修改后,ip产生变化,就需要重新配置,因此,k8s提供了service资源用于解决这

    2024年02月22日
    浏览(42)
  • ClusterIP in K8s

    ClusterIP is a type of Service in Kubernetes that is designed to provide internal network connectivity to a group of pods. The main purpose of ClusterIP is to create a stable, virtual IP address that represents a set of pods and allows other components within the cluster to access them. ClusterIP works by creating a virtual IP address for the Service, which

    2024年02月11日
    浏览(53)
  • Service 在 K8s 中的四种类型

    CSDN话题挑战赛第2期 参赛话题:万家争鸣的云计算修罗场 ClusterIP模式 clusterIP 主要在每个 node 节点使用 iptables,将发向 clusterIP 对应端口的数据,转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法,并可以查询到这个 service 下对应 pod 的地址和端口,进而把数据

    2024年02月14日
    浏览(40)
  • k8s的资源类型

    Kubernetes(通常称为K8s)是一种用于自动化部署、扩展和管理容器化应用程序的开源平台。它提供了一个强大的容器编排和管理系统,可以简化容器化应用程序的部署、伸缩和运维。 在Kubernetes中,容器是最基本的部署单元,而容器化应用程序由一个或多个容器组成。Kubernete

    2024年02月05日
    浏览(39)
  • K8S Headless 与 ClusterIP的区别

    在Kubernetes中,Headless Service和ClusterIP Service都是Service资源的类型,它们都用于为应用程序提供服务发现和负载均衡等功能。下面是Headless Service和ClusterIP Service的区别: Headless Service是一种不使用ClusterIP的Service类型,它会将应用程序的访问请求直接转发到后端Pod上,而不进行任

    2024年02月07日
    浏览(34)
  • 在K8S中,DaemonSet类型资源特性?

    在Kubernetes(简称K8S)中,DaemonSet是一种控制器资源对象,它的主要特性包括: 每个节点运行一个实例 : DaemonSet确保集群中的每个工作节点上都运行着一个指定的Pod副本。这意味着当DaemonSet被创建时,系统会自动调度Pod到所有符合条件的节点上,确保每个节点上都有且仅有一

    2024年02月19日
    浏览(38)
  • K8s中Role(ClusterRole)资源类型rules字段详解

    在Kubernetes(K8s)中,Role资源类型的 rules字段用于定义哪些操作(verbs)可以在哪些资源(resources)上执行 。Role是一种命名空间级别的资源,它允许你对命名空间内的资源进行细粒度的访问控制。 resources : resources 字段指定了角色可以访问的资源类型。这些资源类型可以是

    2024年03月10日
    浏览(35)
  • k8s基础概念:port ,targetport,nodeport

    在Kubernetes中,有三种类型的端口与Service相关: port 、 targetPort 和 NodePort 。它们分别用于不同的用途: port : port 字段定义了Service暴露给集群内部和外部的端口号。当你创建一个Service时,其他应用或服务可以通过该端口与Service进行通信,将请求发送到Service上。这个端口号是

    2024年02月09日
    浏览(33)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包