nginx ingress的具體使用
一、ingress概述
1、概述
Kubernetes是一個(gè)擁有強(qiáng)大故障恢復(fù)功能的集群，當(dāng)pod掛掉時(shí)，集群會(huì)重新創(chuàng)建一個(gè)pod出來(lái)，但是pod的IP也會(huì)隨之發(fā)生變化，為了應(yīng)對(duì)這種情況，引入了service，通過(guò)service的標(biāo)簽匹配，來(lái)進(jìn)行后端的pod服務(wù)發(fā)現(xiàn)，并提供傳輸層的負(fù)載均衡。然后我們?cè)偻ㄟ^(guò)service的nodeport模式將端口映射到宿主機(jī)，這樣我們就完成了集群內(nèi)的服務(wù)對(duì)外暴漏。
但是如果我們想配置基于http的負(fù)載均衡，怎么辦呢？可能會(huì)想到，再部署一個(gè)nginx的pod，以daemonset的形式運(yùn)行在集群內(nèi)，綁定宿主機(jī)的80端口，后端直接配置對(duì)應(yīng)的serivce就可以了，
但是當(dāng)后端有新的服務(wù)的時(shí)候，就需要更新nginx pod的配置文件，會(huì)比較麻煩。這個(gè)時(shí)候，ingress就出現(xiàn)了。ingress就是原來(lái)你需要修改nginx配置文件，現(xiàn)在把它做成了一個(gè)ingress對(duì)象，可以通過(guò)yaml的形式進(jìn)行創(chuàng)建，ingress controller的功能就是與apiesrver交互，發(fā)現(xiàn)ingress配置文件的變化，生成nginx可以理解的配置，在寫到nginx 的配置文件中
2、功能
- 將Kubernetes內(nèi)部的服務(wù)暴漏出去
- 提供基于http層的流量負(fù)載均衡（基于主機(jī)頭或者URL）
- 提供TLS/SSL加密
ingress是通過(guò)service的服務(wù)發(fā)現(xiàn)功能來(lái)發(fā)現(xiàn)后端的pod，然后流量直接發(fā)給pod，而不經(jīng)由service，所以要比nodeport的方式網(wǎng)絡(luò)損耗更小。
3、核心概念
- host：未指定
host，因此該規(guī)則適用于通過(guò)指定 IP 地址的所有入站 HTTP 通信。 如果提供了host（例如 foo.bar.com），則rules適用于該host - rules：用于定義當(dāng)前Ingress資源的轉(zhuǎn)發(fā)規(guī)則列表；由rules定義規(guī)則，或沒(méi)有匹配到規(guī)則時(shí)，所有的流量會(huì)轉(zhuǎn)發(fā)到由backend定義的默認(rèn)后端。
- backend：默認(rèn)的后端用于服務(wù)那些沒(méi)有匹配到任何規(guī)則的請(qǐng)求；定義Ingress資源時(shí)，必須要定義backend或rules兩者之一，該字段用于讓負(fù)載均衡器指定一個(gè)全局默認(rèn)的后端。
- tls：TLS配置，目前僅支持通過(guò)默認(rèn)端口443提供服務(wù)，如果要配置指定的列表成員指向不同的主機(jī)，則需要通過(guò)SNI TLS擴(kuò)展機(jī)制來(lái)支持該功能。
4、nginx-ingress工作原理
- ingress-controller通過(guò)和API server交互，動(dòng)態(tài)的獲取ingress的規(guī)則變化
- 當(dāng)ingress發(fā)生變化時(shí)，按照固定格式生成nginxi可以識(shí)別的前后端配置文件
- 再將這段配置文件，寫入到 ingress-controller中的nginx服務(wù)中，在reload一下，使配置文件生效
二、nginx-ingress使用
1、安裝
官網(wǎng)地址：https://kubernetes.github.io/ingress-nginx/deploy/
#以yaml形式進(jìn)行部署 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/baremetal/deploy.yaml #helm進(jìn)行部署 helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace
2、ingress暴露服務(wù)的方式
方式一：Deployment+LoadBalancer模式的Service
如果要把ingress部署在公有云，那用這種方式比較合適。用Deployment部署ingress-controller，創(chuàng)建一個(gè) type為 LoadBalancer 的 service 關(guān)聯(lián)這組 pod。大部分公有云，都會(huì)為 LoadBalancer 的 service 自動(dòng)創(chuàng)建一個(gè)負(fù)載均衡器，通常還綁定了公網(wǎng)地址。 只要把域名解析指向該地址，就實(shí)現(xiàn)了集群服務(wù)的對(duì)外暴露
方式二：DaemonSet+HostNetwork+nodeSelect
用DaemonSet結(jié)合nodeSelect把pod部署到固定節(jié)點(diǎn)上，再通過(guò)HostNetWork直接講pod與宿主機(jī)的的網(wǎng)絡(luò)打通，直接使用宿主機(jī)的80/443端口進(jìn)行訪問(wèn)，這種方式整個(gè)請(qǐng)求鏈路更簡(jiǎn)單，性能相比較NodePort的方式更好，缺點(diǎn)是一個(gè)主機(jī)只能部署一個(gè)pod。
方式三：Deployment+NodePort模式的Service
用Deployment部署ingress-controller，創(chuàng)建一個(gè) type為NodePort的service，這樣就會(huì)暴露在集群節(jié)點(diǎn)的特定端口上面，由于NodePort暴露的端口不是80/443端口，一般前端還會(huì)加一個(gè)負(fù)載均衡，或者把域名解析到node節(jié)點(diǎn)的公網(wǎng)ip上。由于多了一層nat轉(zhuǎn)發(fā)性能會(huì)不如方式二
3、基于主機(jī)名作負(fù)載均衡
注意：通配符匹配要求http host頭部字段與通配符規(guī)則中的后綴部分相同。（例如：*.foo.com 匹配 bar.foo.com, 但不匹配 bar.bar.foo.com）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-wildcard-host
annotations:
kubernetes.io/ingress.class: "nginx" ##指定Ingress Controller的類型
nginx.ingress.kubernetes.io/use-regex: "true" ##指定后面rules定義的path可以使用正則表達(dá)式
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600" ##連接超時(shí)時(shí)間,默認(rèn)為5s
nginx.ingress.kubernetes.io/proxy-send-timeout: "600" ##后端服務(wù)器回轉(zhuǎn)數(shù)據(jù)超時(shí)時(shí)間,默認(rèn)為60s
nginx.ingress.kubernetes.io/proxy-read-timeout: "600" ##后端服務(wù)器響應(yīng)超時(shí)時(shí)間,默認(rèn)為60s
nginx.ingress.kubernetes.io/proxy-body-size: "10m" ##客戶端上傳文件，最大大小，默認(rèn)為20m
#nginx.ingress.kubernetes.io/rewrite-target: / ##URL重寫
nginx.ingress.kubernetes.io/app-root: /index.html
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- pathType: Prefix
path: "/bar"
backend:
service:
name: service1
port:
number: 80
- host: "*.foo.com"
http:
paths:
- pathType: Prefix
path: "/foo"
backend:
service:
name: service2
port:
number: 80
4、基于URL做負(fù)載均衡
注意：如果路徑的最后一個(gè)元素是請(qǐng)求路徑中的最后一個(gè)元素的子字符串，則不會(huì)匹配，（例如：/foo/bar 匹配 /foo/bar/baz, 但不匹配 /foo/barbaz）
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: nginx-web
annotations:
kubernetes.io/ingress.class: "nginx" ##指定Ingress Controller的類型
nginx.ingress.kubernetes.io/use-regex: "true" ##指定后面rules定義的path可以使用正則表達(dá)式
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600" ##連接超時(shí)時(shí)間,默認(rèn)為5s
nginx.ingress.kubernetes.io/proxy-send-timeout: "600" ##后端服務(wù)器回轉(zhuǎn)數(shù)據(jù)超時(shí)時(shí)間,默認(rèn)為60s
nginx.ingress.kubernetes.io/proxy-read-timeout: "600" ##后端服務(wù)器響應(yīng)超時(shí)時(shí)間,默認(rèn)為60s
nginx.ingress.kubernetes.io/proxy-body-size: "10m" ##客戶端上傳文件，最大大小，默認(rèn)為20m
#nginx.ingress.kubernetes.io/rewrite-target: / ##URL重寫
nginx.ingress.kubernetes.io/app-root: /index.html
spec:
rules:
- host: www.jiege.com
http:
paths:
- path: /app1
backend:
serviceName: magedu-tomcat-app1-service
servicePort: 80
- path: /app2
backend:
serviceName: magedu-tomcat-app2-service
servicePort: 80
5、配置TLS加密
可以將證書先配置為secrt類型來(lái)做保護(hù)，ingress只支持單個(gè)TLS端口443
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: nginx-web
spec:
rules:
- host: www.jiege.com
http:
paths:
- path: /app1
backend:
serviceName: magedu-tomcat-app1-service
servicePort: 80
- path: /app2
backend:
serviceName: magedu-tomcat-app2-service
servicePort: 80
注意：默認(rèn)規(guī)則上無(wú)法使用TLS，因?yàn)樾枰蛩锌赡艿淖佑蛎l(fā)放證書，因此，TLS字段中，hosts的值需要與rules字段中hosts完全匹配。
示例：
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: nginx-web
namespace: magedu
annotations:
kubernetes.io/ingress.class: "nginx" ##指定Ingress Controller的類型
nginx.ingress.kubernetes.io/ssl-redirect: 'true' ##開啟重定向
spec:
tls:
- hosts:
- www.jiege.com
secretName: tls-secret
- hosts:
- mobile.jiege.com
secretName: mobile-tls-secret
rules:
- host: www.jiege.com
http:
paths:
- path: /
backend:
serviceName: magedu-tomcat-app1-service
servicePort: 80
- host: mobile.jiege.com
http:
paths:
- path: /
backend:
serviceName: magedu-tomcat-app2-service
servicePort: 80
6、Annotations注解
注解用來(lái)配置當(dāng)前ingress資源實(shí)例中的Nginx虛擬主機(jī)相關(guān)的配置，也就是通過(guò)Annotations來(lái)開啟一些nginx功能
示例
| 注解 | 類型 | 功能描述 |
|---|---|---|
| nginx.ingress.kubernetes.io/enable-access-log | true 或 false | 對(duì)當(dāng)前虛擬主機(jī)設(shè)置是否啟用訪問(wèn)日志，默認(rèn)為真 |
| nginx.ingress.kubernetes.io/client-body-buffer-size | string | 同 Nginx 配置指令 client_body_buffer_size |
| nginx.ingress.kubernetes.io/use-regex | true 或 false | 是否對(duì)當(dāng)前虛擬主機(jī)的 Nginx 指令 location 使用正則方式進(jìn)行路徑匹配，默認(rèn)值為 false |
| nginx.ingress.kubernetes.io/custom-http-errors | []int | 根據(jù)響應(yīng)碼狀態(tài)定義為錯(cuò)誤狀態(tài)并跳轉(zhuǎn)到設(shè)置的默認(rèn)后端 |
| nginx.ingress.kubernetes.io/default-backend | string | 自定義默認(rèn)后端的資源對(duì)象 Service 名稱，當(dāng)客戶端的請(qǐng)求沒(méi)有匹配的 Nginx 規(guī)則或響應(yīng)錯(cuò)誤時(shí)，將被轉(zhuǎn)發(fā)到默認(rèn)后端 |
| nginx.ingress.kubernetes.io/permanent-redirect | string | 設(shè)置永久重定向的目標(biāo)地址 |
| nginx.ingress.kubernetes.io/permanent-redirect-code | number | 自定義永久重定向的響應(yīng)碼，默認(rèn)為 301 |
| nginx.ingress.kubernetes.io/rewrite-target | URI | 同 Nginx 配置指令 rewrite |
| nginx.ingress.kubernetes.io/limit-rate | number | 訪問(wèn)流量速度限制，同 Nginx 配置指令 limit_rate |
| nginx.ingress.kubernetes.io/limit-connections | number | 節(jié)并發(fā)連接數(shù)限制，同 Nginx 配置指令 limit_conn |
| nginx.ingress.kubernetes.io/enable-global-auth | true 或 false | 如果 ConfigMap 的 global-auth-url 被設(shè)置，Nginx 會(huì)將所有的請(qǐng)求重定向到提供身份驗(yàn)證的 URL，默認(rèn)為 true |
| nginx.ingress.kubernetes.io/service-upstream | true 或 false | 默認(rèn) Nginx 以 Service 中 Pod 的 IP 和端口為 Upstream 中的成員列表，該參數(shù)為 true 時(shí)，將以 Service 的 ClusterIP 和端口為被代理入口，該功能避免了因 Pod 漂移帶來(lái)的 Upstream 的配置變化 |
| nginx.ingress.kubernetes.io/backend-protocol | НТТР 或 HTTPS 或 GRPC 或 GRPCS 或 AJP 或 FCGI | 設(shè)置代理后端服務(wù)器的代理協(xié)議類型，默認(rèn)為 HTTP |
| nginx.ingress.kubernetes.io/load-balance | round_robin 或 ewma | 設(shè)置負(fù)載均衡算法，基于 balancer_by_lua 模塊實(shí)現(xiàn)，支持輪詢和 Peak EWMA 兩種負(fù)載算法 |
到此這篇關(guān)于nginx ingress的具體使用的文章就介紹到這了,更多相關(guān)nginx ingress內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
- nginx-ingress-controller日志持久化方案的解決
- k8s部署ingress-nginx的方法步驟
- nginx?ingress代理websocket流量的配置方法
- 解決國(guó)內(nèi)k8s的ingress-nginx鏡像無(wú)法正常pull拉取問(wèn)題
- k8s之ingress-nginx詳解和部署方案
- 安裝ingress-nginx遇到的一些坑實(shí)戰(zhàn)記錄
- nginx?ingress限速那些事淺析
- 使用Nginx Ingress 優(yōu)雅顯示錯(cuò)誤頁(yè)面
- nginx-ingress-controller部署配置詳解
- k8s部署ingress-nginx的詳細(xì)步驟大全
- Nginx?ingress?controller高可用的實(shí)現(xiàn)
相關(guān)文章
有時(shí)我們想共享電腦上的某些文件,一個(gè)比較方便的做法是,開一個(gè)HTTP服務(wù),指向文件所在的目錄,這次我們用 nginx 來(lái)實(shí)現(xiàn)這個(gè)需求,本文將通過(guò)代碼示例一步步教你使用Nginx來(lái)共享文件,需要的朋友可以參考下2025-01-01
本文介紹了Nginx keepalive配置的概念和作用,闡述了keepalive連接的基本原理和優(yōu)勢(shì),并給出了一些常用的配置示例,具有一定的參考價(jià)值,感興趣的可以了解一下2023-09-09
網(wǎng)頁(yè)502?Bad?Gateway?nginx/1.20.1報(bào)錯(cuò)的原因與解決方法
502 bad gateway nginx/1.20.1 是一個(gè)錯(cuò)誤提示,通常出現(xiàn)在訪問(wèn)網(wǎng)站時(shí)出現(xiàn)問(wèn)題,這篇文章主要給大家介紹了關(guān)于網(wǎng)頁(yè)502?Bad?Gateway?nginx/1.20.1報(bào)錯(cuò)的原因與解決方法,需要的朋友可以參考下2024-03-03
基于Nginx的衍生版服務(wù)器Tengine簡(jiǎn)介
這篇文章主要介紹了基于Nginx的衍生版服務(wù)器Tengine簡(jiǎn)介,本文講解了Nginx的特性、Tengine的特性、架構(gòu)和擴(kuò)展性等內(nèi)容,需要的朋友可以參考下2015-03-03
Windows nginx安裝教程及簡(jiǎn)單實(shí)踐
這篇文章主要介紹了Windows nginx安裝教程及簡(jiǎn)單實(shí)踐的相關(guān)資料,需要的朋友可以參考下2016-10-10
Nginx作為一款強(qiáng)大的反向代理服務(wù)和負(fù)載均衡服務(wù),而健康檢查是為了保障nginx能夠準(zhǔn)確的轉(zhuǎn)發(fā)到后端的可用服務(wù),本文主要介紹了nginx增加健康檢查接口的實(shí)現(xiàn)示例,感興趣的可以了解一下2024-02-02
負(fù)載均衡下的webshell上傳+nginx解析漏洞的過(guò)程
這篇文章主要介紹了負(fù)載均衡下的webshell上傳+nginx解析漏洞,首先介紹了負(fù)載均衡下webshell上傳的四大難點(diǎn)及環(huán)境搭建教程,感興趣的朋友跟隨小編一起看看吧2024-02-02
這里簡(jiǎn)單記錄一下在mac系統(tǒng)下安裝nginx的方法，推薦給大家，有需要的小伙伴可以參考下。2015-03-03
前端加載訪問(wèn)速度優(yōu)化詳細(xì)指南(Nginx)
在前端開發(fā)中,優(yōu)化頁(yè)面加載速度成為了開發(fā)者的一項(xiàng)重要任務(wù),下面這篇文章主要給大家介紹了關(guān)于前端加載訪問(wèn)速度優(yōu)化(Nginx)的相關(guān)資料,文中通過(guò)代碼介紹的非常詳細(xì),需要的朋友可以參考下2024-06-06
如果我們使用了nginx去作為反向代理或者負(fù)載均衡，從客戶端過(guò)來(lái)的長(zhǎng)連接請(qǐng)求就會(huì)被轉(zhuǎn)換成短連接發(fā)送給服務(wù)器端。為了支持長(zhǎng)連接，我們需要在nginx服務(wù)器上做一些配置。2020-10-10