• docker version:20.10.2

  • kubernetes version:1.20.1

本文概述Kubernetes Service的基本原理和使用。

服务

Service是将运行在一组Pods上的应用程序公开网络服务的抽象方法。

每个Pod都有自己的IP地址,但是在Deployment中,在同一时刻运行的Pod集合可能与之后运行该应用程序的Pod集合不同。如果一组Pod(称为“后端”)为集群内其他Pod(称为“前端”)提供功能,那么前端如何找出并跟踪要连接的IP地址,以便前端可以使用提供工作负载的后端部分?-- service

Service所针对的Pod集合通常是通过标签选择器来确定的。

定义Service

示例:

下面配置创建一个名称为"my-service"的Service对象,它会将请求代理到具有“app=MyApp”标签、TCP端口9376的Pod上。

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376

Service会分配一个IP地址(集群IP,VIP),通过标签选择器的控制器不断扫描与其匹配的Pod,将其更新发布到Service的Endpoint对象。

没有标签选择器的Service

ExternalName Service是Service的特例,它没有选择算符,但是使用DNS名称。

当希望使用集群外部的服务时,可使用此方式。

示例:

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
---
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 192.0.2.42
ports:
- port: 9376

虚拟IP和Service代理

在集群中,每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP(虚拟IP)形式。

userspace代理模式

用户空间代理模式下kube-proxy会监视Service对象和Endpoint对象的添加和移除操作。对每个Service,它会再本地Node上打开一个端口(随机选择)。任何连接到“代理端口”的请求,都会被代理到Service的后端Pods中的某个。使用哪个后端Pod,是kube-proxy基于SessionAffinity来确认的。

最后它配置iptables规则,捕获到达该Service的clusterIP(虚拟IP)和Port的请求,并重定向到代理端口,代理端口再代理请求到后端Pod。

默认情况下,用户空间模式下的kube-proxy通过轮询算法选择后端。

![services-userspace-overview]](https://img2020.cnblogs.com/blog/2286432/202102/2286432-20210225140728527-1532153658.png)

iptables代理模式

这种模式,kube-proxy会监视Service对象和Endpoint对象的添加和移除。对每个Service,它会配置iptables规则,从而捕获到达该Service的clusterIP和端口的请求,进而将请求重定向到Service的一组后端中的某个Pod。对于每个Endpoint对象,它也会配置iptables规则,这个规则会选择一个后端组合。

默认的策略是,kube-proxy在iptables模式下随机选择一个后端。

使用iptables处理流量具有较低的系统开销,因为流量由Linux netfilter处理,而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。

如果kube-proxy在iptables模式下运行,并且所选的第一个Pod没有响应,则连接失败。这与用户空间模式不同,在用户空间模式下的这种情况,kube-proxy将检测到与第一个Pod的连接已失败,并会自动使用其他后端Pod重试。

可以使用Pod就绪探测器验证后端Pod可以正常工作,以便iptables模式下的kube-proxy仅看到测试正常的后端。这样做意味着你避免将流量通过kube-proxy发送到已知已失败的Pod。

IPVS代理模式

在ipvs模式下,kube-proxy监视service和Endpoint,调用netlink接口相应地创建IPVS规则,并定期将IPVS规则与Kubernetes服务和端点同步。该控制循环可确保IPVS状态与所需状态匹配。访问服务时,IPVS将流量定向到后端Pod之一。

IPVS代理模式类似于iptables模式的netfilter挂钩函数,但是使用哈希表作为基础数据结构,并且在内核空间中工作。这意味着,与iptables模式下的kube-proxy相比,IPVS模式下的kube-proxy重定向通信的延迟要短,并且在同步代理规则时具有更好的性能。与其他模式相比,IPVS模式还支持更高的网络流量吞吐量。

IPVS提供更多选项来平衡后端Pod的流量:

  • rr:轮询(Round-Robin)
  • lc:最少链接(Least Connection)
  • dh:目标地址哈希(Destination Hashing)
  • sh:源地址哈希(Source Hashing)
  • sed:最短预期延迟(Shortest Expected Delay)
  • nq:从不排队(Never Queue)

要在IPVS模式下运行kube-proxy,必须在启动kube-proxy之前使IPVS在节点上可用。

当kube-proxy以IPVS代理模式启动时,它将验证IPVS内核模块是否可用。如果未检测到IPVS内核模块,则kube-proxy将退回到以iptables代理模式运行。

无头服务

无头服务(Headless Service)并不会分配Cluster IP,kube-proxy不会处理它们,也不会为它们进行负载均衡和路由。DNS如何实现自动配置,依赖于Service是否定义了标签选择器。

通过指定ClusterIP(spec.clusterIP)的值为None来创建HeadlessService。

带有标签选择器的服务

定义了标签选择器的无头服务,Endpoint控制器在API中创建了Endpoints记录,并且修改DNS配置返回A记录,通过这个地址直接到达Service的后端Pod上。

无标签选择器的服务

对没有定义标签选择器的无头服务,Endpoint控制器不会创建Endpoints记录。然后DNS系统会查找和配置:

- 对于ExternalName类型的服务,查找其CNAME记录。
- 对所有其他类型的服务,查找与Service名称相同的任何Endpoints记录。

Kubernetes-6.Service的更多相关文章

  1. kubernetes进阶(04)kubernetes的service

    一.service概念 Service是对一组提供相同功能的Pods的抽象,并为它们提供一个统一的入口.借助Service,应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级.Service ...

  2. [Kubernetes]说说 Service 与 Ingress

    在 Kubernetes 中, Service 有三种对外暴露的方法,但是由于每个 Service 都要有一个负载均衡的服务,所以采用 Service 的话,会造成既浪费成本又高的现象.对于用户来说, ...

  3. 【Kubernetes】Kubernetes的Service外部访问方式:NodePort和LoadBalancer

    Kubernetes的Pod的寿命是有限的,它们不会复活,因此尽管每个Pod都有自己的IP地址,但是这些IP地址是不可靠的,会随着Pod的消亡而消失. 这就带来一个问题,如果一些Pod的集合(称之为b ...

  4. Kubernetes的Service运行原理

    一.为什么Servcie能定位到Pod 因为Pod的IP是不固定的,所以Kubernetes需要Service,除此之外它还可以在多个Pod间负载均衡 Service的访问入口,其实是宿主机的kube ...

  5. Kubernetes中Service的使用

    目录 简介 1. Service资源定义 1.1 Service Type ClusterIP 无头service NodePort sessionAffinity实现源地址session绑定 简介 ...

  6. kubernetes 简单service的例子

    首先建一个Deployment: apiVersion: apps/v1beta1 kind: Deployment metadata: name: httpd spec: replicas: 3 t ...

  7. kubernetes的Service Account和secret

    系列目录 Service Account Service Account概念的引入是基于这样的使用场景:运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它 ...

  8. kubernetes学习Service之headless和statefulSet结合

    一.首先说headless Service和普通Service的区别 headless不分配clusterIP headless service可以通过解析service的DNS,返回所有Pod的地址 ...

  9. kubernetes之service

    service出现的动机 Kubernetes Pods 是有生命周期的.他们可以被创建,而且销毁不会再启动. 如果您使用 Deployment 来运行您的应用程序,则它可以动态创建和销毁 Pod. ...

  10. 阿里云Kubernetes服务 - Service Broker快速入门指南

    4月底阿里云容器服务上线了基于Kubernetes集群的服务目录功能.阿里云的容器的服务目录遵循Open Service Broker API标准,提供了一系列的服务代理组件,实现了对主流开源服务如M ...

随机推荐

  1. Codeforces Round #667 (Div. 3)

    比赛链接:https://codeforces.com/contest/1409 A. Yet Another Two Integers Problem 题意 给出两个数 $a$ 和 $b$,有以下两 ...

  2. hdu4126Genghis Khan the Conqueror (最小生成树+树形dp)

    Time Limit: 10000/5000 MS (Java/Others)    Memory Limit: 327680/327680 K (Java/Others) Total Submiss ...

  3. hdu4291 A Short problem

    Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 32768/32768 K (Java/Others) Total Submission ...

  4. hdu5289 Assignment

    Time Limit: 4000/2000 MS (Java/Others)    Memory Limit: 65536/65536 K (Java/Others) Total Submission ...

  5. CF1474-C. Array Destruction

    CF1474-C. Array Destruction 题意: 题目给出一个长度为\(2n\)的正整数序列,现在问你是否存在一个\(x\)使得可以不断的进行如下操作,直到这个序列变为空: 从序列中找到 ...

  6. pyspark Py4JJavaError: Unsupported class file major version 56

    在jupyter notebook跑上面的代码的时候报错Py4JJavaError: An error occurred while calling z:org.apache.spark.mllib. ...

  7. Leetcode(877)-石子游戏

    亚历克斯和李用几堆石子在做游戏.偶数堆石子排成一行,每堆都有正整数颗石子 piles[i] . 游戏以谁手中的石子最多来决出胜负.石子的总数是奇数,所以没有平局. 亚历克斯和李轮流进行,亚历克斯先开始 ...

  8. C# 类 (7) - 抽象 Abstract

    Abstract 抽象类,关键字Abstract ,最典型的应用就是在 继承机制里 作为base类,抽象类是不能被实例化的(前面说的static 类也不能被实例化)它必须作为 基类,被别人继承,然后必 ...

  9. 洛谷p2216 多次单调队列,扫描矩阵中的最大值减去最小值最的固定大小子矩阵

    #include <iostream> #include <cstdio> #include <cstring> using namespace std; int ...

  10. USB2.0协议学习笔记---描述符

     USB设备描述符 字段名 长  度(字节)  地址偏移 含           义 bLenth   1  0  描述符长度 bDescriptorType   1  1 描述符类型 (这里为 1) ...