一般 nginx 做主機反向代理（網關）有以下配置
其中 192.168.1.10:5001，192.168.1.10:5001 我們把他們稱為 Endpoint，就是所謂的具體的服務，比如 order 訂單服務。
nginx-ingress也是一種代理，是一個pod，外部的資料統一經過（必經）這個pod，然後通過該pod内部的nginx方向代理到各各服務（Endpoint）。nginx-ingress是ingress控制器插件的一種，這些插件有很多，比如istio-ingressgateway。
nginx-ingress pod有兩個功能，controller 和 nginx：
“ controller：和kubernetes api通訊實時更新nginx配置（就是ingress yaml資源了） nginx：正常的反向代理
與主機nginx的差別是，該pod nginx-ingress是運作在pod裡。主機在定義反向代理配置檔案時，需要監聽一個對外開放的端口，比如上邊的80端口。那麼pod中的nginx端口是如何配置的呢？
我們在github上找到了nginx-ingress的deployment.yaml
其中一段
我們看到
預設對外監聽了兩個端口80和443，也就是說，有這兩個端口對外就可以web服務了。
ingress 資源通過yaml進行管理的，比如以下：
以上我們定義了一個單一規則的ingress，該pod（nginx-ingress）接收到外部所有的請求，将被發送到内部order服務的80端口上。接下來我們看pod（nginx-ingress）如何把ingress資源轉化為該pod中的nginx反向代理配置檔案
當然ingress如果包含https，那麼會轉化nginx對應的443端口及證書的配置檔案内容，這裡就不寫了。
那麼，單一個規則的ingress資源代理多個服務（比如order服務，product服務）或者多個ingress資源檔案如何轉化為nginx配置？猜測，其實就是轉化成了多個。
當然，被轉化的nginx配置檔案要比這些複雜的多，據說還是用lua腳本寫的，靈活如openresty。
一般來講，pod直接對外提供服務就隻有兩種方式：
create一個service，該service暴漏nodePort
forward 映射
我們一般采用第一種。
nginx-ingress也是一個pod，是以，為了能使外部通過該pod代理通路，還需要nginx-ingress對外提供一個nodePort的service。這個service這裡也不再寫了。
我們可以看到，因為 nginx-ingress 這個pod做了所有service的代理，在高并發情況下将承受巨大壓力，我們可以增加多個pod執行個體。
作者：dakesolo
連結：https://juejin.cn/post/6844903957479817230