主機nginx

一般nginx做主機反向代理（網(wǎng)關）有以下配置

upstream order{

server 192.168.1.10:5001;

server 192.168.1.11:5001;

}

server {

listen 80;

server_name order.example.com;

access_log /var/log/nginx/order.example.com-access.log;

error_log /var/log/nginx/order.example.com-error.log;

location / {

proxy_pass_header Server;

proxy_set_header Host $http_host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Scheme $scheme;

proxy_pass http://order;

}

}

復制代碼

其中192.168.1.10:5001，192.168.1.10:5001我們把他們稱為Endpoint，就是所謂的具體的服務，比如order訂單服務。

pod nginx-ingress

nginx-ingress也是一種代理，是一個pod，外部的數(shù)據(jù)統(tǒng)一經過（必經）這個pod，然后通過該pod內部的nginx方向代理到各各服務（Endpoint）。nginx-ingress是ingress控制器插件的一種，這些插件有很多，比如istio-ingressgateway。

1、Pod

nginx-ingress pod有兩個功能，controller和nginx：

controller：和kubernetes api通訊實時更新nginx配置（就是ingress yaml資源了）

nginx：正常的反向代理

復制代碼

與主機nginx的區(qū)別是，該pod nginx-ingress是運行在pod里。主機在定義反向代理配置文件時，需要監(jiān)聽一個對外開放的端口，比如上邊的80端口。那么pod中的nginx端口是如何配置的呢？我們在github上找到了nginx-ingress的deployment.yaml

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml

復制代碼

其中一段

apiVersion： apps/v1

kind： Deployment

metadata：

name： nginx-ingress-controller

namespace： ingress-nginx

labels：

app.kubernetes.io/name： ingress-nginx

app.kubernetes.io/part-of： ingress-nginx

spec：

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：

# wait up to five minutes for the drain of connections

terminationGracePeriodSeconds： 300

serviceAccountName： nginx-ingress-serviceaccount

containers：

- name： nginx-ingress-controller

image： quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1

。。。

。。。

。。。

ports：

- name： http

containerPort： 80

- name： https

containerPort： 443

復制代碼

我們看到

- name： http

containerPort： 80

- name： https

containerPort： 443

復制代碼

默認對外監(jiān)聽了兩個端口80和443，也就是說，有這兩個端口對外就可以web服務了。

2、ingress 資源

ingress 資源通過yaml進行管理的，比如以下：

apiVersion： extensions/v1beta1

kind： Ingress

metadata：

name： order

spec：

rules：

- host： order.example.com

http：

paths： /

backend：

serviceName： order

servicePort： 80

復制代碼

以上我們定義了一個單一規(guī)則的ingress，該pod（nginx-ingress）接收到外部所有的請求，將被發(fā)送到內部order服務的80端口上。接下來我們看pod（nginx-ingress）如何把ingress資源轉化為該pod中的nginx反向代理配置文件

upstream order{

server order:80;

}

server {

listen 80;

server_name order.example.com;

。。。

。。。

location / {

proxy_pass_header Server;

proxy_set_header Host $http_host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Scheme $scheme;

proxy_pass http://order; # 對應ingress 資源 name： order

}

}

復制代碼

當然ingress如果包含https，那么會轉化nginx對應的443端口及證書的配置文件內容，這里就不寫了。

那么，單一個規(guī)則的ingress資源代理多個服務（比如order服務，product服務）或者多個ingress資源文件如何轉化為nginx配置？猜測，其實就是轉化成了多個

upstream order{

server order:80;

}

復制代碼

當然，被轉化的nginx配置文件要比這些復雜的多，據(jù)說還是用lua腳本寫的，靈活如openresty。

3、nginx-ingress對外提供服務

一般來講，pod直接對外提供服務就只有兩種方式：

create一個service，該service暴漏nodePort

forward 映射

我們一般采用第一種。nginx-ingress也是一個pod，所以，為了能使外部通過該pod代理訪問，還需要nginx-ingress對外提供一個nodePort的service。這個service這里也不再寫了。

4、nginx-ingress工作流程

我們可以看到，因為nginx-ingress這個pod做了所有service的代理，在高并發(fā)情況下將承受巨大壓力，我們可以增加多個pod實例。

來源：掘金 - dakesolo

編輯：jq