k8s Service 实现服务发现和负载均衡

目录
  • 前言
  • Service 介绍
  • Service 的四种类型及使用方式
  • Service 的定义和使用
    • 通过命令创建服务
    • 查看创建的服务情况
  • 不指定 Selectors 的服务
  • Headless 服务
  • Service 工作原理及原理图
  • Ingress 讲解
  • 集群外部如何访问服务
  • 总结

前言

本文将介绍 Kubernetes 的资源对象 Service,内容包括 Service 介绍、Service 的四种类型及使用方式、不指定 Selectors 的服务、Headless 服务、Service 工作原理及原理图。同时也会讲解 Ingress 和集群外部如何访问服务。

在容器编排系统中,如 Kubernetes,Pod 是最小的部署单元。而一组 Pod 通常对外提供某种服务。在 Kubernetes 中,Service 就是用来对外暴露一组 Pod 的服务的资源对象。Service 可以通过 IP 地址和端口号访问,从而对外提供服务。

Service 介绍

Service 是 Kubernetes 中一个非常重要的概念,它可以将一组 Pod 封装成一个逻辑服务单元。

Service 可以通过定义的 Label Selector,将一组 Pod 绑定到一起,形成一个 Service。通过 Service,用户可以方便地访问这个服务,不需要关心 Pod 的具体 IP 地址和端口号,也不需要担心 Pod 的数量变化会影响服务的访问。

Service 的四种类型及使用方式

Kubernetes 中的 Service 一共有四种类型,分别是 ClusterIP、NodePort、LoadBalancer 和 ExternalName。

  • ClusterIP:是 Service 的默认类型,它会为 Service 创建一个 Cluster IP,这个 IP 只能在集群内部访问。通过 ClusterIP,用户可以访问该 Service 关联的 Pod。
  • NodePort:在每个节点上绑定一个端口,从而将 Service 暴露到集群外部。用户可以通过任意一个节点的 IP 地址和该端口号来访问 Service。
  • LoadBalancer:在云厂商提供的负载均衡器上创建一个 VIP,从而将 Service 暴露到集群外部。用户可以通过该 VIP 地址来访问 Service。
  • ExternalName:可以将 Service 映射到集群外部的一个 DNS 名称上,从而将 Service 暴露到集群外部。

另外,也可以将已有的服务以 Service 的形式加入到 Kubernetes 集群中来,只需要在创建 Service 的时候不指定 Label selector,而是在 Service 创建好后手动为其添加 endpoint。

Service 的定义和使用

Service 也是可以通过 yaml 来定义的。

以下是带有 selector 和 type 的 YAML 文件定义一个名为 nginx 的 Service,将服务的 80 端口转发到 default namespace 中带有标签 run=nginx 的 Pod 的 80 端口:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    run: nginx
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

其中,type 为 Service 的类型,可以取值为 ClusterIP、NodePort、LoadBalancer 和 ExternalName。

本例中的 type 为 ClusterIP,表示该 Service 的类型为 ClusterIP。

以下是通过命令创建及查看创建的服务情况的操作步骤和预期的展示内容。

通过命令创建服务

使用 kubectl create 命令创建一个名为 nginx 的服务,并将服务的 80 端口转发到 default namespace 中带有标签 run=nginx 的 Pod 的 80 端口。运行以下命令:

kubectl create service clusterip nginx --tcp=80:80 --dry-run=client -o yaml > nginx-service.yaml

这个命令将在当前目录下生成一个名为 nginx-service.yaml 的 YAML 文件,其中包含了创建 Service 所需的配置信息。

预期展示内容:

service/nginx created (dry run)

使用 kubectl apply 命令创建 Service。运行以下命令:

kubectl apply -f nginx-service.yaml

这个命令将根据 YAML 文件中的配置信息创建一个名为 nginx 的 Service。

预期展示内容:

service/nginx created

查看创建的服务情况

使用 kubectl get 命令查看已经创建的 Service。运行以下命令:

kubectl get services

这个命令将显示所有已经创建的 Service,包括它们的名称、类型、Cluster IP、端口等信息。

预期展示内容:

NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP    4h19m
nginx        ClusterIP   10.96.58.173   <none>        80/TCP     1m

使用 kubectl describe 命令查看指定 Service 的详细信息。运行以下命令:

kubectl describe service nginx

这个命令将显示名为 nginx 的 Service 的详细信息,包括它的类型、Cluster IP、端口、Selector 等信息。

预期展示内容:

Name:              nginx
Namespace:         default
Labels:            run=nginx
Annotations:       <none>
Selector:          run=nginx
Type:              ClusterIP
IP:                10.96.58.173
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.7:80
Session Affinity:  None
Events:            <none>

不指定 Selectors 的服务

当用户创建 Service 的时候,可以不指定 Label Selector,这种 Service 被称为无选择器服务(no selector service)。无选择器服务不能和 Pod 绑定,而只是提供一个固定的 IP 和端口,用于访问后端服务。这种服务通常用于代理到外部的服务,如数据库、消息队列等。

Headless 服务

Kubernetes 中的 Service 还有一个特殊的类型,叫做 Headless 服务。Headless 服务的 ClusterIP 为 None,它不会为 Service 创建 Cluster IP。通过 Headless 服务,用户可以直接访问该 Service 关联的 Pod,而不需要通过 Service 进行访问。

Service 工作原理及原理图

Service 的工作原理是通过代理模式实现的,即 kube-proxy 负责将 service 负载均衡到后端 Pod 中。

当用户通过 Service 的 IP 和端口访问 Service 时,请求会先到达 Service 代理,然后由代理将请求转发给后端的 Pod。

当 Pod 发生变化时,Service 会自动更新 Endpoint,从而保证请求能够正确地到达后端 Pod。

以下是 Service 工作原理的原理图:

Ingress 讲解

Ingress 是 Kubernetes 中另一个重要的资源对象,它用于将集群外部的 HTTP(S) 流量路由到集群内部的 Service。通过 Ingress,用户可以在集群外部定义一个域名,然后将该域名路由到 Service 中。Ingress 可以实现灰度发布、负载均衡、SSL 终止等功能。

集群外部如何访问服务

当用户需要从集群外部访问 Kubernetes 中的 Service 时,可以通过 NodePort、LoadBalancer 或 Ingress 来实现。具体方式如下:

  • NodePort

用户可以通过任意一个节点的 IP 地址和该节点上绑定的端口号来访问 Service。例如,如果 NodePort 的端口为 30080,节点 IP 地址为 192.168.0.10,则用户可以通过 http://192.168.0.10:30080 访问该 Service。

  • LoadBalancer

当 Service 的类型为 LoadBalancer 时,云厂商会在其提供的负载均衡器上为 Service 创建一个 VIP,用户可以通过该 VIP 地址来访问 Service。

  • Ingress

通过 Ingress,用户可以在集群外部定义一个域名,并将该域名路由到 Service 中。用户可以通过该域名来访问 Service。

总结

以上是关于 Kubernetes 中的 Service 的介绍,包括 Service 介绍和定义、Service 的四种类型 Service 工作原理、Ingress 讲解以及集群外部如何访问服务。

在使用 Service 时,用户不需要关心 Pod 的具体 IP 地址和端口号,也不需要担心 Pod 的数量变化会影响服务的访问。

通过 Ingress,用户可以在集群外部定义一个域名,然后将该域名路由到 Service 中,从而实现灰度发布、负载均衡、SSL 终止等功能。

以上就是k8s Service 实现服务发现和负载均衡的详细内容,更多关于k8s Service服务发现负载均衡的资料请关注我们其它相关文章!

(0)

相关推荐

  • 不同k8s集群间服务如何相互访问实现详解

    目录 1 | 春天来了一个需求 1.1 | 现状 1.2 | 需求 2 | 方案有挺多的 3 | 展开来讲讲 3.1 | 场景 1 3.2 | 场景 2 4 | 说点非技术的 1 | 春天来了一个需求 1.1 | 现状 不同工程团队有各自的 k8s 开发集群, 负责的服务部署在各自的集群上 但是这些服务之间存在调用关系(单项或者双向的) 不同 k8s 集群之间内网是联通的 其中一个集群要作为流量入口,面向用户 1.2 | 需求 实现服务跨集群访问 服务之间只能通过内网调用 统一的外部流量接入控制

  • K8S之StatefulSet有状态服务详解

    目录 一.概念 二.实例 一.概念 1.1.无状态和有状态的区别 主要从网络和存储来对比 无状态不考虑存储和网络,可以任意漂移,每个副本是一样的,如Nginx 有状态应用需要考虑存储和网络,每个副本是不对等的,具有唯一的ID,如etcd.mysql 1.2.StatefulSet的特点 专为部署有状态服务而生 解决Pod独立生命周期,保持Pod启动顺序和唯一性 应用场景:分布式应用.数据库集群 稳定,唯一的网络标识符,持久存储有序,优雅的部署和扩展.删除.终止有序,滚动更新 1.3.Headle

  • 服务发现与负载均衡机制Service实例创建

    目录 什么是Service? 创建一个Service实例 集群外部访问svc 创建代理外部应用的Service实例 Service反代外部域名 Service 的类型: 什么是Service? Service是逻辑上的一组Pod,一种可以访问Pod的策略,而且其他Pod可以通过Service访问到这个Service代理的Pod,可以把它理解为传统架构中的反向代理. 相对于Pod而言,Service有一个固定的名称,不会发生改变,并且提供了负载均衡的功能. 通过Service的定义,可以对客户端应

  • 浅谈服务发现和负载均衡的来龙去脉

    问题缘由 随着时代发展,单机程序遇到了计算力和存储的双重瓶颈,分布式架构应运而生.单体应用通过函数名(标识)便可轻松完成本地函数调用,在分布式系统中,服务(RPC/RESTful API)承担了类似的角色,但请求服务单靠服务名还不够,服务名只是服务能力(服务类型)的标识,还需要指示服务位于网络何处,而部署在云中的服务实例IP是动态分配的,扩缩容.失败和更新则让问题变得更加复杂,静态配置服务实例适应不了新变化,需要更精细化的服务治理能力,为了解决或者说简化这个问题,服务发现作为一种基础能力被抽象和

  • 详解Docker Swarm服务发现和负载均衡原理

    本文将介绍基于 DNS 的负载均衡.基于 VIP 的负载均衡和路由网格(Routing Mesh). 使用的技术 Docker 使用了 Linux 内核 iptables 和 IPVS 的功能来实现服务发现和负载均衡. iptables 是 Linux 内核中可用的包过滤技术,它可用于根据数据包的内容进行分类.修改和转发决策. IPVS 是 Linux 内核中可用的传输级负载均衡器. 准备工作 swarm 集群: [Manager]node1.[Worker]node2 客户端镜像: regis

  • Spring Cloud Alibaba Nacos服务治理平台,服务注册、RestTemplate实现微服务之间访问负载均衡访问的问题

    目录 Nacos简介 ☘Spring Cloud 组件依赖版本 ☘Nacos部署 ☘访问Nacos平台 Nacos服务注册.微服务访问.负载均衡实现 nacos-consumer微服务创建 ☘nacos-provider微服务创建 测试 Nacos简介 Github:https://github.com/alibaba/nacos官网文档:https://nacos.io/zh-cn/docs/what-is-nacos.htmlNacos 提供了发现.配置和管理微服务能力,能快速实现动态服务发

  • springcloud中Ribbon和RestTemplate实现服务调用与负载均衡

    文件目录结构 文件目录结构很重要,特别注意的是rule文件要放在主启动类上一级位置,才能够扫描. 写pom <dependencies> <!--springboot 2.2.2--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependenc

  • k8s 中的 service 如何找到绑定的 Pod 及实现 Pod 负载均衡的方法

    目录 k8s 中的 service 如何找到绑定的 Pod 以及如何实现 Pod 负载均衡 前言 endpoint kube-proxy userspace 模式 iptables ipvs kernelspace 服务发现 环境变量 DNS 总结 参考 k8s 中的 service 如何找到绑定的 Pod 以及如何实现 Pod 负载均衡 前言 Service 资源主要用于为 Pod 对象提供一个固定.统一的访问接口及负载均衡的能力. service 是一组具有相同 label pod 集合的抽

  • k8s service使用详解(云原生kubernetes)

    目录 一.什么是服务service? 二.service分类 2.1 ClusterIP 2.2 NodePort 2.3 LoadBalancer(付费方案) 2.4 ExternalName (使用较少) 三.service和pod的关系 四.Service 之 ClusterIP 使用 4.1 在当前目录下,创建一个deploy-nginx-pod.yaml,配置如下 4.2 暴露服务为 clusterIP 类型 4.3 查看服务 五.Service 之 NodePort 使用 5.1 关

  • ASP.NET Core3.1 Ocelot负载均衡的实现

    1.负载均衡 Ocelot可以在每个路由的可用下游服务中实现负载均衡,这使我们更有效地选择下游服务来处理请求.负载均衡类型: LeastConnection:根据服务正在处理请求量的情况来决定哪个服务来处理新请求,即将新请求发送到具有最少现有请求的服务去处理.算法状态没有分布在Ocelot集群中. RoundRobin:遍历可用服务并发送请求.算法状态没有分布在Ocelot集群中. NoLoadBalancer:从配置或服务发现中获取第一个可用服务来处理新请求. CookieStickySess

  • linux负载均衡总结性说明 四层负载和七层负载有什么区别

    在常规运维工作中,经常会运用到负载均衡服务.负载均衡分为四层负载和七层负载,那么这两者之间有什么不同? 废话不多说,详解如下: 一.什么是负载均衡 1)负载均衡(Load Balance)建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽.增加吞吐量.加强网络数据处理能力.提高网络的灵活性和可用性.负载均衡有两方面的含义:首先,大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间:其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点

  • 负载均衡的基本知识以及使用nginx进行负载均衡的简单例子

    nginx一般可以用于七层的负载均衡,这篇文章将介绍一些负载均衡的基本知识以及使用nginx进行负载均衡的简单的例子. 四层负载均衡 vs 七层负载均衡 经常会说七层负载均衡还是四层负载均衡,其实根据ISO的OSI网络模型的所在层的叫法而决定的,nginx因为在使用http协议在应用层进行负载均衡的操作,所以被称为七层负载均衡.而诸如LVS在TCP层进行负载均衡操作的则被称为四层负载均衡.一般来说,有如下层的负载均衡分类: 常见软件的支持 常见的负载均衡算法 负载均衡常见有如下几种算法: 负载均

随机推荐