从零开始的云计算生活——第四十七天，细水长流，kubernetes模块之ingress资源对象
目录
一.故事背景
二.ingress概述
版本对比图
三. Ingress应用案例
2.1 环境准备
搭建ingress环境
2.2 验证-NodePort模式
修改ingress代理模式
准备service和pod
设置Http代理
2.3 验证-LoadBalancer模式
修改ARP模式，启用严格ARP模式
搭建metallb支持LoadBalancer
普通的service测试
四.总结
一.故事背景
本节内容比较重要，通过lngress模块可以进行域名访问，本次只介绍该模块
二.ingress概述
Service对集群之外暴露服务的主要方式有两种：NotePort和LoadBalancer，但是这两种方式，都有一定的缺点：
-
NodePort方式的缺点是会占用很多集群机器的端口，那么当集群服务变多的时候，这个缺点就愈发明显。
-
LB方式的缺点是每个service需要一个LB，浪费、麻烦，并且需要kubernetes之外设备的支持。
基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示：
实际上，Ingress相当于一个7层的负载均衡器，是kubernetes对反向代理的一个抽象，它的工作原理类似于Nginx，可以理解成在Ingress里建立诸多映射规则，Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。在这里有两个核心概念：
-
ingress：kubernetes中的一个对象，作用是定义请求如何转发到service的规则
-
ingress controller：具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如Nginx, Contour, Haproxy等等
Ingress（以Nginx为例）的工作原理如下：
-
用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service
-
Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置
-
Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中的pod，并动态更新
-
到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则
版本对比图
三. Ingress应用案例
2.1 环境准备
搭建ingress环境
在三个节点上拷贝lngress安装包，并解压
在master节点拷
进行解压
进入以下路径，修改配置文件
将447行划线删除（因为使用的是保存的镜像，后边的码是没有的）
548，601行同理
保存后运行yaml文件
检查状态，成功启动
2.2 验证-NodePort模式
此刻注意，loadBalancer模式的service必须有外部负载均衡器，并且还得支持dhcp分配功能，否则如下图EXternal-IP会一直是pending状态，所以进行修改
修改ingress代理模式
kubectl -n ingress-nginx edit svc ingress-nginx-controller
将最后的type类型改成NodePort
然后再次查看
准备service和pod
创建nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx-deployname: nginx-deploy
spec:replicas: 3selector:matchLabels:app: nginx-deploytemplate:metadata:labels:app: nginx-deployspec:containers:- image: nginx:latestimagePullPolicy: IfNotPresentname: nginxports:- containerPort: 80
---apiVersion: v1
kind: Service
metadata:labels:app: nginx-deployname: nginx-svc
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: nginx-deploytype: ClusterIP
稍等片刻完成创建
设置Http代理
设置ingress管理规则
apiVersion: networking.k8s.io/v1
kind: Ingress # 创建一个类型为Ingress的资源
metadata:name: nginx-ingress # 这个资源的名字为 nginx-ingress
spec:ingressClassName: nginx # 使用nginxrules:- host: nginx.jx.com # 访问此内容的域名http:paths:- backend:service:name: nginx-svc # 对应nginx的服务名字,该规则的namespace必须与service的一致port:number: 80 # 访问的端口path: / # 匹配规则pathType: Prefix # 匹配类型，这里为前缀匹配#Exact（精确匹配）：
#当 PathType 的值为 Exact 时，意味着服务的路由规则将仅在传入请求的路径与指定的路径完全相同时才会被匹配。
#例如，如果一个服务的路径配置为 /api/v1/resource 且 PathType 为 Exact，那么只有当请求的路径是 /api/v1/resource 时，该服务才会被选中处理请求，多一个字符或少一个字符都不会匹配，包括 /api/v1/resource/ 或者 /api/v1/resource?id=1 这样的请求路径都不会被该服务处理，这是一种非常严格的精确匹配规则。#Prefix（前缀匹配）：
#当 PathType 的值为 Prefix 时，服务将匹配以指定路径作为前缀的请求路径。
#例如，如果一个服务的路径配置为 /api/v1 且 PathType 为 Prefix，那么 /api/v1、/api/v1/resource、/api/v1/resource/1 等以 /api/v1 开头的请求路径都会被该服务处理，只要请求路径以 /api/v1 开头，该服务就会处理该请求，而不要求请求路径完全等于 /api/v1。
创建
查看
查看详情
（在访问节点写入hosts解析记录,由于ingress-controller运行在node1节点，所以hosts要写成node1的节点IP地址，经过测试写集群中任意节点都可以，主也可以，节点也可以，都可以访问）
测试，只能使用域名访问
2.3 验证-LoadBalancer模式
修改ARP模式，启用严格ARP模式
# 执行修改操作
kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl apply -f - -n kube-system#或者
kubectl get configmap kube-proxy -n kube-system -o yaml | sed -e "s/strictARP: false/strictARP: true/" | kubectl apply -f - -n kube-system
#查看修改结果
kubectl edit configmap -n kube-system kube-proxy
为什么要修改严格模式？
-
避免 ARP 冲突
-
在默认情况下，容器网络可能会出现一些非预期的 ARP 行为。在 Load Balancer 模式下，流量需要准确地被分发到后端的 Pod。如果不启用严格 ARP 模式，可能会出现多个 Pod 响应同一个 ARP 请求的情况。
-
例如，假设在一个集群中有多个 Pod 提供相同的服务，并且它们在同一个子网中。如果没有严格的 ARP 控制，负载均衡器可能会收到来自多个 Pod 的 ARP 响应，导致流量分发混乱，影响服务的正常运行。
-
-
确保流量正确分发
-
严格 ARP 模式可以确保只有正确的后端 Pod 响应 ARP 请求。这样，负载均衡器能够准确地将流量发送到预期的 Pod。
-
以一个 Web 应用程序为例，当外部用户通过负载均衡器访问该应用时，负载均衡器需要将请求发送到正确的 Web 服务器 Pod。通过启用严格 ARP 模式，就像是给每个 Pod 一个 “专属标签”，只有拥有该标签（正确 MAC 地址）的 Pod 才会响应 ARP 请求，从而保证请求能够准确无误地到达提供服务的 Pod。
-
-
增强网络安全性和稳定性
-
限制 ARP 响应可以防止恶意的 Pod 或者受到攻击的 Pod 干扰网络通信。如果一个被入侵的 Pod 随意响应 ARP 请求，可能会导致中间人攻击或者流量劫持等安全问题。
-
严格 ARP 模式可以防止这种情况的发生，使得网络通信更加安全和稳定。例如，在一个多租户的 Kubernetes 集群环境中，不同租户的 Pod 之间通过严格的 ARP 模式来隔离网络通信，避免租户之间的相互干扰和安全威胁。
-
搭建metallb支持LoadBalancer
Metallb 在 Kubernetes 中的作用主要是为没有运行在如 AWS、GCP 等具有完善网络服务的云平台上的集群，提供网络负载均衡器的实现。
-
实现 LoadBalancer 服务类型：在 Kubernetes 中，Service 有多种类型，其中 LoadBalancer 类型通常需要外部的负载均衡器支持。Metallb 可以在缺乏原生云平台负载均衡支持的环境下，模拟实现 LoadBalancer 类型的 Service。它能够为应用提供可从集群外部访问的固定 IP 地址。
-
IP 地址分配与管理：负责在指定的 IP 地址范围（IP address pool）内，为 LoadBalancer 类型的 Service 分配 IP 地址，并确保这些 IP 地址的正确映射和管理，使外部流量能够准确地路由到相应的 Kubernetes 服务后端 Pod。
-
提供高可用的网络连接：通过实现 BGP（Border Gateway Protocol）或 Layer2 模式的负载均衡机制，确保即使在节点故障或网络波动的情况下，也能维持应用的外部网络连接的稳定性和可靠性。
进入文件夹中编辑文件
创建IP地址池
cat >IPAddressPool.yaml<<EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:name: planip-pool #这里与下面的L2Advertisement的ip池名称需要一样namespace: metallb-system
spec:addresses:- 192.168.71.135-192.168.71.150 #自定义ip段
EOF关联IP地址池
cat >L2Advertisement.yaml<<EOF
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:name: planip-poolnamespace: metallb-system
spec:ipAddressPools:- planip-pool #这里需要跟上面ip池的名称保持一致
EOF
普通的service测试
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx-deploy1name: nginx-deploy1
spec:replicas: 3selector:matchLabels:app: nginx-deploy1template:metadata:labels:app: nginx-deploy1spec:containers:- image: nginximagePullPolicy: IfNotPresentname: nginx1ports:- containerPort: 80
---apiVersion: v1
kind: Service
metadata:labels:app: nginx-deploy1name: nginx-svc1
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: nginx-deploy1type: LoadBalancer修改ingress管理规则（新加以下字段）
- host: nginx2.jx.com # 访问此内容的域名http:paths:- backend:service:name: nginx-svc1 # 对应nginx的服务名字port:number: 80 # 访问的端口path: / # 匹配规则pathType: Prefix # 匹配类型，这里为前缀匹配
此时观察到新增加域名 （之前将nginx.jx.com改为了一个副本，所以只有一个地址）
修改ingress模式：
改回LoadBalancer
验证访问
此时404是因为只能访问域名，访问域名可以达到界面。
四.总结
本文介绍了Kubernetes中Ingress的概念及其应用。Ingress通过定义请求转发规则解决了NodePort和LoadBalancer方式的缺点（端口占用和资源浪费问题），其核心由Ingress资源对象和Ingress控制器组成。文章详细演示了在NodePort和LoadBalancer两种模式下配置Ingress环境的步骤，包括创建Service/Pod、设置代理规则等关键操作。特别说明了LoadBalancer模式下需启用严格ARP模式避免冲突，并介绍了Metallb工具的作用。最终通过域名访问验证了Ingress的功能实现。