标签：Ingress Java Service service 负载 访问 Kubernetes 我们

这种模式与 iptables 模式形似，kube-proxy 会监控pod的变化并且创建相应的 ipvs 规则。但是 ipvs 规则相对于 iptables 来说转发效率更高，而且支持更多的 LB 算法。

实践

上面了解到3种工作模式。我们来简单试一下 ipvs 的作用。首先准备一份资源清单：

这份清单上半部分是创建一个 Pod控制器，下半部分是创建一个 Service。

然后我们输入 ipvsadm -Ln命令即可看到 ipvs规则策略：

10.108.230.12 是 service 提供的访问入口，当访问这个入口的时候，可以发现后面有三个 pod 的服务在等待调用，kube-proxy 会基于 rr(轮询)的策略，将请求分发到其中一个pod上去，这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以!

此模式必须安装 ipvs 内核模块，否则会降低为 iptables

开启 ipvs：

kubectl edit cm kube-proxy -n kube

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

-system

编辑后保存(:wq) 退出

kubectl delete pod -l k8s-app=kube-proxy -n kube-system ipvsadm -Ln

2)Service 使用

上面已经介绍完了 Service 的几种工作模式。下面我们进入Service 的使用阶段。我们上面已经做了简单的实践，创建了一个 Deploy ，一个 Service ，然后我们可以通过 serviceIp + targetPort 或 nodeIp + nodePort访问资源

但是在学习 Service 的使用，仅仅这个是不够的，Service又分为5种类型，下面将一一介绍。

1. ClusterIP

我们先看下 ClusterIP 类型的Service的资源清单：

通过创建后测试访问 clusterIp + port

我们再查看下 ipvs 规则，可以看到该service已经可以转发到对应的3个pod上

接下来我们可以通过 describe 指令查看该service有哪些信息：

扫了一遍发现 Endpoints 和 Session Affinity 都是我们之间没有见过的。那这个又是个什么东西呢?

Endpoint

Endpoint 是 k8s 中的一个资源对象，存储在etcd中，用来记录一个 service 对应的所有Pod 的访问地址，它是根据 service 配置文件中 selector 描述产生的。一个Service由一组Pod组成，这些Pod通过 Endpoint 暴露出来，可以说 Endpoint 是实际实现服务的端口的集合。通俗来说，Endpoint 是 service 和 pod 之间的桥梁

既然是一个资源，那么我们就可以获取到

负载分发

我们上面已经成功的实现了通过 Service 访问到Pod 资源，那么我们再做一些修改，分别进入3个pod编辑 usr/share/nginx/index.html 文件：

pod01 Pod01 : ip - 10.244.1.73 # pod02 Pod01 : ip - 10.244.1.73 # pod03 Pod03 : ip - 10.244.2.63

然后我们再次尝试通过 curl 10.96.10.10:80命令查看结果：

眼尖的你是否有发现，这种负载分发策略不就是轮询吗!对于 Service 的访问，k8s提供了两种负载分发策略：

• 如果未定义分发策略，默认使用 kube-proxy 的策略，比如随机、轮询

• 基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个pod上。而这里就需要用到我们上面提到的没有见过的东西 sessionAffinity

之前我们用 ipvsadm -Ln 命令查看分发策略的时候，里面有个 rr 字段不知道你有没有注意到，没错，这个 rr 值得就是轮询的意思

如果我们想要开启会话保持的分发策略，那么只需要在spec中添加 sessionAffinity:ClientIP 选项

再次通过 ipvsadm -Ln 命令查看分发策略就可以发现结果已经发生变化了

我们简单测试一下：

这样子就已经实现了会话保持的分发策略!

注意：ClusterIp 的 Service，不支持外部访问，也就是说通过浏览器访问是不生效的，只能在集群内部访问

2. HeadLiness

很多服务都需要支持定制化，如果将产品定位为服务，那么这个产品毋庸是成功。在某些场景中，开发人员并不想要使用 service 提供的负载均衡功能，而是希望自己来控制负载均衡策略。针对这种情况的发生，k8s也是很好的支持了，引入了 HeadLiness Service，这类 Service 不会分配 ClusterIp，如果想要访问 service，只能通过 Service 域名进行查询。

我们来看下 HeadLiness 的资源清单模板：

唯一跟 ClusterIp 不同的便是 clusterIP: None 属性的变化。

通过创建后可以发现，ClusterIP并未分配，我们继续查看 Service 的详情

通过详情我们可以发现 Endpoints 已经生效了，然后我们任意进入到一个pod中，查看域名解析情况：

可以看到域名也已经解析完成，默认域名为service名称.命名空间.svc.cluster.local

3. NodePort

上面的两个service类型，都是只能在集群内部才能访问，但是我们部署服务肯定是想让用户通过集群外部可以使用的。那么这个时候就需要用到我们开头创建的service类型，那就是 NodePort service。

这种类型的Service的工作原理也不难，其实 就是将 service的端口映射到 Node 的一个端口上，然后通过 NodeIp+NodePort进行访问

看了原理图是不是感觉豁然开朗啦。那么来看看是怎么通过资源清单创建的：

我们通过以上资源清单创建service，然后访问：

可以看出通过两种方式都是可以访问的，我们也可以在浏览器试试看：

这结果也是如我们所愿!

不要感觉到这里就已经心满意足了哦，虽然说已经可以成功让用户访问到了我们趁热打铁继续再了解剩下的两种类型

4. LoadBalancer

LoadBalancer 听名字就知道跟负载均衡有关。这个类型与 NodePort 很相似，目的都是向外部暴露一个端口，主要的区别在于 LoadBalancer 会在集群的外部再做一个负载均衡器，而这个设备是需要外部环境支持的，外部环境发送到这个设备的请求，会被设备负载之后转发到集群中。

图中有个Vip的概念，这里的Vip指的是 Vitual IP，也就是虚拟IP，外部用户通过访问这个虚拟IP，可以负载到我们不同的service上，达到负载均衡和高可用的特点

5. ExternalName

ExternalName 类型的service 是用于引入集群外部的服务，它通过 externalName 属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部服务了。

资源清单：

创建后我们可以查看域名解析，发现已经解析成功：

dig @10.96.0.10 svc-externalname.cbuc-test.svc.cluster.local

二、Ingress

1)工作模式

上面我们已经讲完了 Service几种类型的用法，我们已经知晓了想让外部用户访问到我们pod中的服务有两种类型的service是支持的，分别是：NodePort和LoadBalancer，但是其实认真分析一下，我们不难发现这两种service 的缺点:

NodePort：会占用集群机器的很多端口，当集群服务变多的时候，这个缺点就越发明显

LoadBalancer：每个Service都需要一个LB，比较麻烦和浪费资源，并且需要 k8s之外的负载均衡设备支持

这种缺点当然不只是我们能够发现，作为k8s的启动者早已意识到了，紧接着便推出了 Ingress 的概念。Ingress 仅需要一个 NodePort或 LB 就可以满足暴露多个Service的需求：

实际上，Ingress就相当于一个7层的负载均衡器，是 K8s 对反向代理的一个抽象，它的工作原理类似于 Nginx，可以理解成在 Ingress 里 建立诸多的隐射规则，然后 Ingress Controller通过监听这些配置规则转化成 Nginx 的反向代理配置，然后对外提供该服务。这边涉及到了两个重要的概念：

• Ingress：K8s 中的一个资源对象，作用是定义请求如何转发到 service 的规则

• Ingress Controller：具体实现反向代理及负载均衡的程序，对Ingress定义的规则进行解析，根据配置的规则来实现请求转发，有很多种实现方式，如 Nginx、Contor、Haproxy等

Ingress 控制器 有很多中可以实现请求转发的方式，我们通常上也会选择我们比较熟悉的 Nginx 作为负载，接下来我们就以 Nginx 为例，我们先来了解一下其工作原理：

• 用户编写 Ingress Service规则， 说明每个域名对应 K8s集群中的哪个Service

• Ingress控制器会动态感知到 Ingress 服务规则的变化，然后生成一段对应的Nginx反向代理配置

• Ingress控制器会将生成的Nginx配置写入到一个运行中的Nginx服务中，并动态更新

• 然后客户端通过访问域名，实际上Nginx会将请求转发到具体的Pod中，到此就完成了整个请求的过程

了解了工作原理，我们就来落地实现~

2)Ingress使用

1. 环境搭建

标签：Ingress,Java,Service,service,负载,访问,Kubernetes,我们
来源： https://blog.csdn.net/m0_64867688/article/details/121903349

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。