k8s-service-基本概念与域名访问

service背景

客户端与pod通信,并得到实时响应。但是Pod因为以下几个特征,导致无法实现预期的通信:
1、Pod是短暂的,他们随时会启动或者关闭
2、Pod的ip地址是动态分布的
3、水平伸缩能力需要Pod对IP地址的透明化管理

service概念

通过service,可以为一组具有相同功能的容器应用提供一个统一的、不变的入口地址,并且将请求进行负载分发到后端的各个容器应用上。客户端不需要知道每个单独的提供服务的Pod的地址,这样,这些Pod就可以在集群中随时被创建、调度和移除。service从设计上看是一个虚拟概念,逻辑上代理后端的Pod。
在这里插入图片描述
内部和外部客户端是通过service连接到Pod:
对于外部客户端,无须关心服务器数量;对于内部客户端,例如前端Pod也通过service连接后端Pod,这样,后端Pod的动态移动也不会对前端Pod造成影响。
通过创建service,就可以通过一个单一稳定的IP地址访问到pod,在整个生命周期内这个地址保持不变。在服务后面的pod可能删除重建,它们的地址可能改变,数量也可能增减,但是始终可以通过服务的单一不变地址访问到这些pod。

特点

1、通过yaml文件创建service
2、三种方法向service发送请求:
(1)由已创建的Pod将请求发送给service;
(2)ssh远程登录到集群的某个节点上,使用curl命令;
(3)通过kubectl exec命令在一个已经存在的Pod中执行curl
3、service的会话亲和性:
(1)多次执行相同的请求,默认是在不同的Pod上被执行;
(2)通过设置sessionAffinity实现同一请求将转发到同一Pod上;
(3)支持两种形式的会话亲和性:None和ClientIP

在这里插入图片描述

域名访问

得益于kube-dns插件,通过修改容器的/etc/resolv.conf配置,可以通过域名的方式访问service。

原理

k8s将service的名称当做域名注册到kube-dns中。从图中可以发现,pod查询DNS是通过ServiceName.Namespace子域名来查询的。当service的默认namespace为default时,域名可以通过ServiceName成功查询。

在这里插入图片描述1、skydns是用于服务发现的开源框架,构建于etcd之上,作用是为pod提供DNS查询接口;
2、etcd是一种开源的分布式键值存储,在kube-dns中的作用是存储skydns的数据;
3、exec-healthz是k8s提供的一种辅助容器,多用于sidecar模式中。它的原理是定期执行指定的linux命令,从而判断当前pod中关键容器的健康状态。在kube-dns场景中的作用就是通过nslookup指令检查DNS查询服务的健康状态,livenessProbe通过访问exec-healthz提供的http api监控健康状态,并在出现故障时重启容器。

kubectl get all -n kube-system
#其他省略
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 49d

域名测试

创建容器验证dns解析

apiVersion: v1
kind: Pod
metadata:
labels:
 name: busybox3
 role: master
name: busybox3
spec:
containers:
  - name: busybox3
    image: docker.io/busybox:1.28.4
    imagePullPolicy: IfNotPresent
    command:
    - sleep
    - "3600"
nslookup   kubia-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
​
Name:      kubia-service
Address 1: 10.107.249.0 kubia-service.ycloans-repayment-namespace.svc.cluster.local

执行nslookup service_name或service_cluster_ip即可显示出该服务的相关信息。
至此DNS服务已配置成功,以后可以直接用service_name来访问该service。 *如果某个service属于不同的namespace,那么在进行service查找时,需要补充该namespace的名称(service_name.namespace),组合成完整的域名,否则会查找失败。

  • 1
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
KubernetesService是一种抽象,用于将一组具有相同标签的Pods暴露给其他应用程序或服务。它提供了负载均衡、服务发现和访问控制的功能,使得应用程序能够稳定地访问到后端的Pods。通过Service,可以使用一个唯一的虚拟IP地址来代表一组Pods,并通过这个IP地址和端口与这组Pods进行通信。 在Kubernetes中,Service只是一个概念,真正起作用的是kube-proxy服务进程。每个节点上都运行着一个kube-proxy服务进程,它会监听Service的变动,并将最新的Service信息转换成对应的访问规则。当创建Service时,会将Service的信息写入etcd,并通知kube-proxy更新相应的访问规则,从而实现对Service的负载均衡和路由转发。 然而,对于某些场景中,开发人员可能不想使用Service提供的负载均衡功能,而是希望自己来控制负载均衡策略。为此,Kubernetes提供了Headless Service。Headless Service不会分配Cluster IP,只能通过Service域名进行查询来访问Service。这样,开发人员可以自定义负载均衡策略,对访问Service的请求进行精细控制。 总结起来,KubernetesService是一种用于暴露一组具有相同标签的Pods的抽象。它提供了负载均衡、服务发现和访问控制的功能。实际上,Service的实现是通过kube-proxy服务进程来完成的,它监听Service的变动,并根据最新的Service信息转换成对应的访问规则。此外,Kubernetes还提供了Headless Service,允许开发人员自定义负载均衡策略。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* [Istio K8S Service](https://download.csdn.net/download/weixin_43707560/12525456)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] - *2* *3* [容器集群k8s从入门到精通之Service详解(第七章)](https://blog.csdn.net/qq_28121913/article/details/119208333)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值