前言：
Kubernetes暴露服务的方式目前只有三种：LoadBlancer Service、NodePort Service、Ingress;这一片主要聊聊Ingress。
一、Ingress
简单说，是一个代理，可以根据配置转发请求到指定的服务上。
1.1 Ingress概念
通俗来讲，ingress和之前提到的Service、Deployment，也是一个k8s的资源类型，ingress用于实现用域名的方式访问k8s内部应用。
Ingress为Kubernetes集群中的服务提供了入口，可以提供负载均衡、SSL终止和基于名称的虚拟主机，在生产环境中常用的Ingress有Treafik、Nginx、HAProxy、Istio等。
1.2 基本概念
在Kubernetesv 1.1版中添加的Ingress用于从集群外部到集群内部Service的HTTP和HTTPS路由，流量从Internet到Ingress再到Services最后到Pod上，通常情况下，Ingress部署在所有的Node节点上。
Ingress可以配置提供服务外部访问的URL、负载均衡、终止SSL，并提供基于域名的虚拟主机。但Ingress不会暴露任意端口或协议。
1.3 为什么需要Ingress资源
由于K8S集群拥有强大的副本控制能力，Pod随时可能从一个节点上被驱逐到另一个节点上，或者直接销毁再来一个新的。
然而伴随着Pod的销毁和重生，Pod的IP等信息不断地在改变，此时使用K8S提供的Service机制可以解决这一问题，Service通过标签选定指定的Pod作为后端服务，并监听这些Pod的变化。
在对外暴露服务时，使用Service的NodePort是一个方法
问题1-如何管理端口
当需要对外暴露的服务量比较多的时候，端口管理的问题变会暴露出来。
此时的一个处理方案是使用一个代理服务（例如nginx）根据请求信息将请求转发到不同的服务器上。
问题2-如何管理转发配置
每当有新服务加入，都需要对该服务的配置进行修改、升级，在服务数量逐渐变多后，该配置项目会变得越来越大，手工修改的风险也会逐渐增高。
那么需要一个工具来简化这一过程，希望可以通过简单的配置动态生成代理中复杂的配置，最好还可以顺手重新加载配置文件。
K8S刚好也提供了此类型资源。
1.4 Pod漂移问题
众所周知 Kubernetes 具有强大的副本控制能力，能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的，还可以动态扩容等，总之一句话，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了；这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上，如下图所示
1.5 端口管理问题
采用 NodePort 方式暴露服务面临一个坑爹的问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；这时候引出的思考问题是 “能不能使用 Nginx 啥的只监听一个端口，比如 80，然后按照域名向后转发？” 这思路很好，简单的实现就是使用 DaemonSet 在每个 node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口(就像 NodePort)，本身又在集群内，那么向后直接转发到相应 Service IP 就行了，如下图所示
1.6 域名分配及动态更新问题
从上面的思路，采用 Nginx 似乎已经解决了问题，但是其实这里面有一个很大缺陷：每次有新服务加入怎么改 Nginx 配置？总不能手动改或者来个 Rolling Update 前端 Nginx Pod 吧？这时候 “伟大而又正直勇敢的” Ingress 登场，如果不算上面的 Nginx，Ingress 只有两大组件：Ingress Controller 和 Ingress
Ingress 这个玩意，简单的理解就是 你原来要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yml 创建，每次不要去改 Nginx 了，直接改 yml 然后创建/更新就行了；那么问题来了：”Nginx 咋整？”
Ingress Controller 这东西就是解决 “Nginx 咋整” 的；Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下，工作流程如下图
当然在实际应用中，最新版本 Kubernetes 已经将 Nginx 与 Ingress Controller 合并为一个组件，所以 Nginx 无需单独部署，只需要部署 Ingress Controller 即可
1.7 Ingress的工作方式
Ingress 工作原理
（1）ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化，
（2）然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置，
（3）再写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中，
（4）然后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。
在使用普通的Service时，集群中每个节点的kube-proxy在监听到Service和Endpoints的变化时，会动态的修改相关的iptables的转发规则。 客户端在访问时通过iptables设置的规则进行路由转发达到访问服务的目的。
而Ingress则跳过了kube-proxy这一层，通过Ingress Controller中的代理配置进行路由转发达到访问目标服务的目的。
实际上可以把IngressController看做一个拥有默认处理后端的代理，根据Ingress资源的配置动态修改代理的配置文件，以实现按照规则转发请求的功能。
1.8 Ingress配置项
type Ingress struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
// Ingess配置。
Spec IngressSpec `json:"spec,omitempty"`
// Ingress资源当前状态。
Status IngressStatus `json:"status,omitempty"`
}
type IngressSpec struct {
// 默认的后端服务，当不匹配所有的Ingress规则的时候使用。
// 一般情况默认后端都在Ingress控制器中配置，该字段不进行声明配置。
// 如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。
Backend *IngressBackend `json:"backend,omitempty"`
// TLS配置。目前Ingress只支持443一种TLS端口。
// 如果列表中有多个不同的hosts，将会在ingress controller支持SNI的情况下,
// 通过使用SNI TLS扩展中声明的主机名，在同个端口下使用多路复用。
TLS []IngressTLS `json:"tls,omitempty"`
// Ingress的规则。未匹配到规则列表中规则的请求将会被转发到默认后端上。
Rules []IngressRule `json:"rules,omitempty"`
}
type IngressBackend struct {
// 服务名。
ServiceName string `json:"serviceName"`
// 服务的端口。
ServicePort intstr.IntOrString `json:"servicePort"`
}
type IngressRule struct {
// 域名。
// 不能使用IP地址，不能使用端口。对HTTP服务使用80端口，HTTPS服务使用443端口。
Host string `json:"host,omitempty"`
// 域名下的具体转发规则。
// 未定义的情况下会将请求转发至默认后端。
IngressRuleValue `json:",inline,omitempty"`
}
type IngressRuleValue struct {
HTTP *HTTPIngressRuleValue `json:"http,omitempty"`
}
type HTTPIngressRuleValue struct {
Paths []HTTPIngressPath `json:"paths"`
}
type HTTPIngressPath struct {
// 匹配的路径，必须以/为开头。
// 未定义的情况下会将请求转发至默认后端。
Path string `json:"path,omitempty"`
// 处理请求的后端服务。
Backend IngressBackend `json:"backend"`
}二、部署使用Ingress
2.1 部署 nginx-ingress-controller
1、部署ingress-controller pod及相关资源
[root@k8s-master opt]# mkdir /opt/ingress
[root@k8s-master opt]# cd ingress/
[root@k8s-master ingress]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
--2022-08-09 17:07:00-- https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
正在解析主机 raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.110.133, 185.199.108.133, ...
正在连接 raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度：5976 (5.8K) [text/plain]
正在保存至: “mandatory.yaml”
100%[===================================================================>] 5,976 --.-K/s 用时 0s
2022-08-09 17:07:00 (99.1 MB/s) - 已保存 “mandatory.yaml” [5976/5976])
[root@k8s-master ingress]# ll
总用量 8
-rw-r--r--. 1 root root 5976 8月 9 17:07 mandatory.yaml
官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml上面的下载地址可能无法下载，可用国内的Gitee地址
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml#mandatory.yaml文件中包含了很多资源的创建，包括namespace、ConfigMap、role，ServiceAccount等等所有部署ingress-controller需要的资源。
2.2 修改ClusterRole资源配置
vim mandatory.yaml
......
apiVersion: rbac.authorization.k8s.io/v1beta1
#RBAC相关资源从1.17版本开始改用rbac.authorization.k8s.io/v1，rbac.authorization.k8s.io/v1beta1在1.22版本即将弃用
kind: ClusterRole
metadata:
name: nginx-ingress-clusterrole
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- configmaps
- endpoints
- nodes
- pods
- secrets
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- "extensions"
- "networking.k8s.io" # （0.25版本）增加 networking.k8s.io Ingress 资源的 api
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- "extensions"
- "networking.k8s.io" # （0.25版本）增加 networking.k8s.io/v1 Ingress 资源的 api
resources:
- ingresses/status
verbs:
- update2.3 ingress 暴露服务的方式
●方式一：Deployment+LoadBalancer 模式的 Service
如果要把ingress部署在公有云，那用这种方式比较合适。用Deployment部署ingress-controller，创建一个 type为 LoadBalancer 的 service 关联这组 pod。大部分公有云，都会为 LoadBalancer 的 service 自动创建一个负载均衡器，通常还绑定了公网地址。 只要把域名解析指向该地址，就实现了集群服务的对外暴露
●方式二：DaemonSet+HostNetwork+nodeSelector
用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用HostNetwork直接把该pod与宿主机node的网络打通，直接使用宿主机的80/433端口就能访问服务。这时，ingress-controller所在的node机器就很类似传统架构的边缘节点，比如机房入口的nginx服务器。该方式整个请求链路最简单，性能相对NodePort模式更好。缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress-controller pod。 比较适合大并发的生产环境使用。
●方式三：Deployment+NodePort模式的Service
同样用deployment模式部署ingress-controller，并创建对应的service，但是type为NodePort。这样，ingress就会暴露在集群节点ip的特定端口上。由于nodeport暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定的环境ip地址不变的场景。
NodePort方式暴露ingress虽然简单方便，但是NodePort多了一层NAT，在请求量级很大时可能对性能会有一定影响。
采用方式二：DaemonSet+HostNetwork+nodeSelector
2.4 指定 nginx-ingress-controller 运行在node02 节点
[root@k8s-master ingress]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane,master 7d1h v1.21.3
k8s-node01 Ready <none> 7d1h v1.21.3
k8s-node02 Ready <none> 7d1h v1.21.3
[root@k8s-master ingress]# kubectl label node k8s-node02 ingress=true
node/k8s-node02 labeled
[root@k8s-master ingress]# kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
k8s-master Ready control-plane,master 7d1h v1.21.3 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
k8s-node01 Ready <none> 7d1h v1.21.3 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node01,kubernetes.io/os=linux
k8s-node02 Ready <none> 7d1h v1.21.3 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,ingress=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node02,kubernetes.io/os=linux
2.5 修改Deployment 为 DaemoSet,指定节点运行，并开启hostNetwork网络
vim mandatory.yaml
...
apiVersion: apps/v1
# 修改 kind
# kind: Deployment
kind: DaemonSet
metadata:
name: nginx-ingress-controller
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
# 删除Replicas
# replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
template:
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
annotations:
prometheus.io/port: "10254"
prometheus.io/scrape: "true"
spec:
# 使用主机网络
hostNetwork: true
# 选择节点运行
nodeSelector:
ingress: "true"
serviceAccountName: nginx-ingress-serviceaccount
......2.6 在所有node节点上传nginx-ingress-controller 镜像压缩包
ingree.contro.tar.gz 到 /opt/ingress 目录，并解压和加载镜像
cd /opt/ingress
tar zxvf ingree.contro.tar.gz
docker load -i ingree.contro.tar
或者使用docker pull拉取镜像
[root@k8s-master ingress]# docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0
2.7 启动nginx-ingress-controller
[root@k8s-master ingress]# kubectl apply -f mandatory.yaml
namespace/ingress-nginx unchanged
configmap/nginx-configuration unchanged
configmap/tcp-services unchanged
configmap/udp-services unchanged
serviceaccount/nginx-ingress-serviceaccount unchanged
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole unchanged
Warning: rbac.authorization.k8s.io/v1beta1 Role is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 Role
role.rbac.authorization.k8s.io/nginx-ingress-role unchanged
Warning: rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding unchanged
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding unchanged
daemonset.apps/nginx-ingress-controller unchanged
[root@k8s-master ingress]# kubectl get pod -n ingress-nginx -o wide
//nginx-ingress-controller 已经运行 node02 节点
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-ingress-controller-nhsxt 1/1 Running 0 50m 192.168.161.18 k8s-node02 <none> <none>
[root@k8s-master ingress]# kubectl get cm,daemonset -n ingress-nginx -o wide
NAME DATA AGE
configmap/ingress-controller-leader-nginx 0 45m
configmap/kube-root-ca.crt 1 67m
configmap/nginx-configuration 0 67m
configmap/tcp-services 0 67m
configmap/udp-services 0 67m
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
daemonset.apps/nginx-ingress-controller 1 1 1 1 1 ingress=true 67m nginx-ingress-controller quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0 app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx
到 node02 节点查看
[root@k8s-node02 ingress]# netstat -lntp | grep nginx
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 117191/nginx: maste
tcp 0 0 0.0.0.0:8181 0.0.0.0:* LISTEN 117191/nginx: maste
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 117191/nginx: maste
tcp6 0 0 :::10254 :::* LISTEN 117165/nginx-ingres
tcp6 0 0 :::80 :::* LISTEN 117191/nginx: maste
tcp6 0 0 :::8181 :::* LISTEN 117191/nginx: maste
tcp6 0 0 :::443 :::* LISTEN 117191/nginx: maste
由于配置了 hostnetwork，nginx 已经在 node 主机本地监听 80/443/8181 端口。其中 8181 是 nginx-controller 默认配置的一个 default backend（Ingress 资源没有匹配的 rule 对象时，流量就会被导向这个 default backend）。
这样，只要访问 node 主机有公网 IP，就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话，可以在多个 node上部署，并在前面再搭建一套 LVS+keepalived 做负载均衡
2.8 创建ingress规则
创建一个deploy和svc
[root@k8s-master ingress]# vim service-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-app
spec:
replicas: 2
seleector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-app-svc
spec:
type: ClusterIP
ports:
- protocol: TCP
prot: 80
targetPort:
selector:
app: nginx
创建ingress
#方法一：（extensions/v1beta1 Ingress 在1.22版本即将弃用）
vim ingress-app.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-app-ingress
spec:
rules:
- host: www.liang.com
http:
paths:
- path: /
backend:
serviceName: nginx-app-svc
servicePort: 80
#方法二：
vim ingress-app.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-app-ingress
spec:
rules:
- host: www.liang.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-app-svc
port:
number: 80 
[root@k8s-master ingress]# kubectl apply -f service-nginx.yaml
deployment.apps/nginx-app unchanged
service/nginx-app-svc created
[root@k8s-master ingress]# kubectl apply -f ingress-app.yaml
ingress.networking.k8s.io/nginx-app-ingress created
[root@k8s-master ingress]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-845d4d9dff-4m44r 0/1 Running 0 15m
nginx-app-845d4d9dff-cvxrz 0/1 Running 0 15m
[root@k8s-master ingress]# kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
nginx-app-ingress <none> www.liang.com 80 15m
2.9 测试访问
本地host添加域名解析
[root@k8s-master ingress]# vim /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.161.16 k8s-master
192.168.161.17 k8s-node01
192.168.161.18 k8s-node02
192.168.161.18 www.liang.com
[root@k8s-master ingress]# curl www.liang.com
2.10 查看 nginx-ingress-controller
[root@k8s-master ingress]# kubectl get pod -n ingress-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-ingress-controller-nhsxt 1/1 Running 0 123m 192.168.161.18 k8s-node02 <none> <none>
[root@k8s-master ingress]# kubectl exec -it nginx-ingress-controller-nhsxt -n ingress-nginx /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
www-data@k8s-node02:/etc/nginx$ more /etc/nginx/nginx.conf
可以看到从 start server www.liang.com 到 end server www.liang.com 之间包含了此域名用于反向代理的配置
文章来源：https://www.toymoban.com/news/detail-798112.html
总结
ingress是k8s集群的请求入口，可以理解为对多个service的再次抽象
通常说的ingress一般包括ingress资源对象及ingress-controller两部分组成
ingress-controller有多种实现，社区原生的是ingress-nginx，根据具体需求选择
ingress自身的暴露有多种方式，需要根据基础环境及业务类型选择合适的方式文章来源地址https://www.toymoban.com/news/detail-798112.html
到了这里，关于K8S中的ingress的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![[云原生] K8s之ingress](https://imgs.yssmx.com/Uploads/2024/04/848037-1.png)
