一、概述
server服务：分为
NotePort和LoadBalancer
-
NodePort方式的缺点是端口范围窄，只有2768个pod，不满足可扩展性
-
LB方式的缺点是每个service需要一个LB，成本高，浪费
基于这种现状，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应用案例
环境准备
搭建ingress环境
创建文件夹
bash
[root@k8s-master01 ~]# mkdir ingress-controller
[root@k8s-master01 ~]# cd ingress-controller/获取ingress-nginx
bash
[root@k8s-master01 ingress-controller]# wget https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.12.0/ingress-nginx-controller-v1.12.0.zip
[root@k8s-master01 ingress-controller]# unzip ingress-nginx-controller-v1.12.0.zip
[root@k8s-master01 ingress-controller]# cd ingress-nginx-controller-v1.12.0/deploy/static/provider/cloud
[root@k8s-master01 cloud]# ls
deploy.yaml kustomization.yaml查看并修改镜像源
bash
[root@k8s-master01 cloud]# cat deploy.yaml | grep -n image
445: image: registry.k8s.io/ingress-nginx/controller:v1.12.0
547: image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.5.0
601: image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.5.0部署
bash
[root@k8s-master01 cloud]# kubectl apply -f deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
[root@k8s-master01 cloud]# kubectl -n ingress-nginx get pod
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-sgksd 0/1 Completed 0 77s
ingress-nginx-admission-patch-f4rdc 0/1 Completed 1 77s
ingress-nginx-controller-565cc5ddd9-2qwnm 1/1 Running 0 77s
[root@k8s-master01 cloud]# kubectl -n ingress-nginx get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.10.103.132 <pending> 80:31502/TCP,443:31020/TCP 96s
ingress-nginx-controller-admission ClusterIP 10.10.227.21 <none> 443/TCP 96s查看集群已经存在的nginx类型
bash
[root@k8s-master01 cloud]# kubectl get ingressclass
NAME CONTROLLER PARAMETERS AGE
nginx k8s.io/ingress-nginx <none> 2m53s验证-NodePort模式
准备service和pod
创建nginx.yaml
bash
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-deploy
name: nginx-svc
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx-deploy
type: ClusterIP
bash
创建
[root@k8s-master01 ingress-controller]# kubectl apply -f nginx.yaml
deployment.apps/nginx-deploy created
service/nginx-svc created
# 查看
[root@k8s-master01 ingress-controller]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deploy-7c7b68644b-26jtl 1/1 Running 0 20s
nginx-deploy-7c7b68644b-5jsmb 1/1 Running 0 20s
nginx-deploy-7c7b68644b-rjc4r 1/1 Running 0 20s
[root@k8s-master01 ingress-controller]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.10.0.1 <none> 443/TCP 13d
nginx-svc ClusterIP 10.10.199.33 <none> 80/TCP 36singress service配置解析
工作原理
-
当外部请求到达某个节点的 NodePort 时：
-
如果该节点上有服务对应的 Pod 在运行，请求会被转发到本地的 Pod
-
如果该节点上没有服务对应的 Pod，请求会被丢弃（返回 TCP RST）
-
-
特点：
-
保留原始客户端 IP（不会做 SNAT）
-
可能导致流量分布不均（只有有 Pod 的节点才会接收流量）
-
适合需要保留客户端源 IP 的场景
-
验证-LoadBalancer模式
修改ARP模式，启用严格ARP模式
bash
执行修改操作
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 模式的负载均衡机制，确保即使在节点故障或网络波动的情况下，也能维持应用的外部网络连接的稳定性和可靠性。