k8s之ingress-nginx詳解和部署方案
本篇是基于k8s-v1.15.0版本,在現(xiàn)有集群上部署ingress。
1、ingress介紹
K8s集群對(duì)外暴露服務(wù)的方式目前只有三種:Loadblancer;Nodeport;ingress
前兩種熟悉起來(lái)比較快,而且使用起來(lái)也比較方便,在此就不進(jìn)行介紹了。
下面詳細(xì)講解下ingress這個(gè)服務(wù),ingress由兩部分組成:
- ingress controller:將新加入的Ingress轉(zhuǎn)化成Nginx的配置文件并使之生效
- ingress服務(wù):將Nginx的配置抽象成一個(gè)Ingress對(duì)象,每添加一個(gè)新的服務(wù)只需寫(xiě)一個(gè)新的Ingress的yaml文件即可
其中ingress controller目前主要有兩種:基于nginx服務(wù)的ingress controller和基于traefik的ingress controller。
而其中traefik的ingress controller,目前支持http和https協(xié)議。由于對(duì)nginx比較熟悉,而且需要使用TCP負(fù)載,所以在此我們選擇的是基于nginx服務(wù)的ingress controller。
但是基于nginx服務(wù)的ingress controller根據(jù)不同的開(kāi)發(fā)公司,又分為k8s社區(qū)的ingres-nginx和nginx公司的nginx-ingress。
在此根據(jù)github上的活躍度和關(guān)注人數(shù),我們選擇的是k8s社區(qū)的ingres-nginx。
k8s社區(qū)提供的ingress,github地址如下:https://github.com/kubernetes/ingress-nginx
nginx社區(qū)提供的ingress,github地址如下:https://github.com/nginxinc/kubernetes-ingress
2、ingress的工作原理
ingress具體的工作原理如下:
step1:ingress contronler通過(guò)與k8s的api進(jìn)行交互,動(dòng)態(tài)的去感知k8s集群中ingress服務(wù)規(guī)則的變化,然后讀取它,并按照定義的ingress規(guī)則,轉(zhuǎn)發(fā)到k8s集群中對(duì)應(yīng)的service。
step2:而這個(gè)ingress規(guī)則寫(xiě)明了哪個(gè)域名對(duì)應(yīng)k8s集群中的哪個(gè)service,然后再根據(jù)ingress-controller中的nginx配置模板,生成一段對(duì)應(yīng)的nginx配置。
step3:然后再把該配置動(dòng)態(tài)的寫(xiě)到ingress-controller的pod里,該ingress-controller的pod里面運(yùn)行著一個(gè)nginx服務(wù),控制器會(huì)把生成的nginx配置寫(xiě)入到nginx的配置文件中,然后reload一下,使其配置生效,以此來(lái)達(dá)到域名分配置及動(dòng)態(tài)更新的效果。
3、ingress可以解決的問(wèn)題
1)動(dòng)態(tài)配置服務(wù)
如果按照傳統(tǒng)方式, 當(dāng)新增加一個(gè)服務(wù)時(shí), 我們可能需要在流量入口加一個(gè)反向代理指向我們新的k8s服務(wù). 而如果用了Ingress, 只需要配置好這個(gè)服務(wù), 當(dāng)服務(wù)啟動(dòng)時(shí), 會(huì)自動(dòng)注冊(cè)到Ingress的中, 不需要而外的操作。
2)減少不必要的端口暴露
配置過(guò)k8s的都清楚, 第一步是要關(guān)閉防火墻的, 主要原因是k8s的很多服務(wù)會(huì)以NodePort方式映射出去, 這樣就相當(dāng)于給宿主機(jī)打了很多孔, 既不安全也不優(yōu)雅. 而Ingress可以避免這個(gè)問(wèn)題, 除了Ingress自身服務(wù)可能需要映射出去, 其他服務(wù)都不要用NodePort方式。
4、部署ingress(deployment的方式)
1)配置文件準(zhǔn)備(粘貼下面網(wǎng)址的yanl文件)
github連接地址:
https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/mandatory.yaml
或者
https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml


2)配置文件介紹和設(shè)置ingress的網(wǎng)絡(luò)模式
1> namespace.yaml
創(chuàng)建一個(gè)獨(dú)立的命名空間 ingress-nginx。
2> configmap.yaml
ConfigMap是存儲(chǔ)通用的配置變量的,類(lèi)似于配置文件,使用戶(hù)可以將分布式系統(tǒng)中用于不同模塊的環(huán)境變量統(tǒng)一到一個(gè)對(duì)象中管理;而它與配置文件的區(qū)別在于它是存在集群的“環(huán)境”中的,并且支持K8S集群中所有通用的操作調(diào)用方式。
從數(shù)據(jù)角度來(lái)看,ConfigMap的類(lèi)型只是鍵值組,用于存儲(chǔ)被Pod或者其他資源對(duì)象(如RC)訪問(wèn)的信息。這與secret的設(shè)計(jì)理念有異曲同工之妙,主要區(qū)別在于ConfigMap通常不用于存儲(chǔ)敏感信息,而只存儲(chǔ)簡(jiǎn)單的文本信息。
ConfigMap可以保存環(huán)境變量的屬性,也可以保存配置文件。
創(chuàng)建pod時(shí),對(duì)configmap進(jìn)行綁定,pod內(nèi)的應(yīng)用可以直接引用ConfigMap的配置。相當(dāng)于configmap為應(yīng)用/運(yùn)行環(huán)境封裝配置。
pod使用ConfigMap,通常用于:設(shè)置環(huán)境變量的值、設(shè)置命令行參數(shù)、創(chuàng)建配置文件。
3> default-backend.yaml
如果外界訪問(wèn)的域名不存在的話,則默認(rèn)轉(zhuǎn)發(fā)到default-http-backend這個(gè)Service,其會(huì)直接返回404。
4> rbac.yaml
負(fù)責(zé)Ingress的RBAC授權(quán)的控制,其創(chuàng)建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding。
5> with-rbac.yaml
是Ingress的核心,用于創(chuàng)建ingress-controller。前面提到過(guò),ingress-controller的作用是將新加入的Ingress進(jìn)行轉(zhuǎn)化為Nginx的配置。
6> 各文件的作用:
- configmap.yaml:提供configmap可以在線更新nginx的配置
- default-backend.yaml:提供一個(gè)缺省的后臺(tái)錯(cuò)誤頁(yè)面 404
- namespace.yaml:創(chuàng)建一個(gè)獨(dú)立的命名空間 ingress-nginx
- rbac.yaml:創(chuàng)建對(duì)應(yīng)的role rolebinding 用于rbac
- tcp-services-configmap.yaml:修改L4負(fù)載均衡配置的configmap
- udp-services-configmap.yaml:修改L4負(fù)載均衡配置的configmap
- with-rbac.yaml:有應(yīng)用rbac的nginx-ingress-controller組件
3)修改配置文件
設(shè)置 hostNetwork: true
由于ingress 使用到物理機(jī)的80/443 端口,所以需要設(shè)置為hostNetwork模式

4)拉取鏡像(通過(guò)查看ingress的yaml文件可以看出)和創(chuàng)建svc文件
拉取鏡像

docker pull quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
或者
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0 kubectl apply -f mandatory.yaml
創(chuàng)建svc:https://github.com/kubernetes/ingress-nginx/blob/master/deploy/baremetal/service-nodeport.yaml

5)指定運(yùn)行節(jié)點(diǎn)(需要打標(biāo)簽)
nginx-ingress-controller會(huì)隨意選擇一個(gè)node節(jié)點(diǎn)運(yùn)行pod,為此需要我們把nginx-ingress-controller運(yùn)行到指定的node節(jié)點(diǎn)上
首先需要給需要運(yùn)行nginx-ingress-controller的node節(jié)點(diǎn)打標(biāo)簽,在此我們把nginx-ingress-controller運(yùn)行在指定的node節(jié)點(diǎn)上
kubectl get nodes –show-labels #先查看各個(gè)node上的lables信息 kubectl label nodes node3 nginx=nginx #給node3打標(biāo)簽 kubectl get nodes –show-labels #查看node3上的lables
修改ingress的yaml文件中的標(biāo)簽



5、部署ingress(DaemonSet的方式)
官方原始文件使用的是deployment,replicate 為 1,這樣將會(huì)在某一臺(tái)節(jié)點(diǎn)上啟動(dòng)對(duì)應(yīng)的nginx-ingress-controller pod。外部流量訪問(wèn)至該節(jié)點(diǎn),由該節(jié)點(diǎn)負(fù)載分擔(dān)至內(nèi)部的service。測(cè)試環(huán)境考慮防止單點(diǎn)故障,改為DaemonSet然后刪掉replicate ,配合親和性部署在制定節(jié)點(diǎn)上啟動(dòng)nginx-ingress-controller pod,確保有多個(gè)節(jié)點(diǎn)啟動(dòng)nginx-ingress-controller pod,后續(xù)將這些節(jié)點(diǎn)加入到外部硬件負(fù)載均衡組實(shí)現(xiàn)高可用性。
1)添加hostNetwork
true:添加該字段,暴露nginx-ingress-controller pod的服務(wù)端口(80)
2)添加親和性屬性
增加親和性部署,有custom/ingress-controller-ready 標(biāo)簽的節(jié)點(diǎn)才會(huì)部署該DaemonSet
3)設(shè)置節(jié)點(diǎn)的label
kubectl label nodes node2 custem/ingress-controller-ready=true kubectl label nodes node3 custem/ingress-controller-ready=true kubectl label nodes node4 custem/ingress-controller-ready=true

4)修改yaml文件(和deployment部署ingress的文件一樣,只需要修改此處即可)

4)執(zhí)行并部署ingress
完整版文件如下
cat mandatory-deamon.yaml
apiVersion: v1
kind: Namespace
metadata:
name: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-configuration
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
name: tcp-services
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
name: udp-services
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
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:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- "extensions"
- "networking.k8s.io"
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- "extensions"
- "networking.k8s.io"
resources:
- ingresses/status
verbs:
- update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: nginx-ingress-role
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- configmaps
- pods
- secrets
- namespaces
verbs:
- get
- apiGroups:
- ""
resources:
- configmaps
resourceNames:
# Defaults to "<election-id>-<ingress-class>"
# Here: "<ingress-controller-leader>-<nginx>"
# This has to be adapted if you change either parameter
# when launching the nginx-ingress-controller.
- "ingress-controller-leader-nginx"
verbs:
- get
- update
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- apiGroups:
- ""
resources:
- endpoints
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: nginx-ingress-role-nisa-binding
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: nginx-ingress-role
subjects:
- kind: ServiceAccount
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: nginx-ingress-clusterrole-nisa-binding
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: nginx-ingress-clusterrole
subjects:
- kind: ServiceAccount
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
---
apiVersion: apps/v1
#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: 2
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
# wait up to five minutes for the drain of connections
terminationGracePeriodSeconds: 300
serviceAccountName: nginx-ingress-serviceaccount
nodeSelector:
kubernetes.io/os: linux
custem/ingress-controller-ready: 'true'
tolerations:
- key: "kubernetes.io/os"
operator: "Equal"
value: "linux"
effect: "NoSchedule"
containers:
- name: nginx-ingress-controller
image: www.my.com/k8s/nginx-ingress-controller:0.30.0
args:
- /nginx-ingress-controller
- --configmap=$(POD_NAMESPACE)/nginx-configuration
- --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
- --udp-services-configmap=$(POD_NAMESPACE)/udp-services
- --publish-service=$(POD_NAMESPACE)/ingress-nginx
- --annotations-prefix=nginx.ingress.kubernetes.io
securityContext:
allowPrivilegeEscalation: true
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
# www-data -> 101
runAsUser: 101
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
ports:
- name: http
containerPort: 80
protocol: TCP
- name: https
containerPort: 443
protocol: TCP
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
lifecycle:
preStop:
exec:
command:
- /wait-shutdown
---
apiVersion: v1
kind: LimitRange
metadata:
name: ingress-nginx
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
limits:
- min:
memory: 90Mi
cpu: 100m
type: Containerkubectl apply -f mandatory-deamon.yaml kubectl get ds -n ingress-nginx kubectl get pod -n ingress-nginx -o wide

注意:大家可能會(huì)想node2上也打了標(biāo)簽,為什么node2上沒(méi)有;原因很簡(jiǎn)單,我的node2是master,已經(jīng)有了污點(diǎn)的標(biāo)簽,從親和性上就已經(jīng)不再容忍任何pod運(yùn)行到master上,所以只能看到node3和node4上有nginx-ingress的pod。
6、案例測(cè)試
1)創(chuàng)建deployment模板并修改
kubectl create deployment httpd --image=www.my.com/web/httpd:latest --dry-run -o yaml > http-dep.yaml

2)創(chuàng)建svc模板并修改
kubectl expose deployment httpd --port=8000 --target-port=80 --type=ClusterIP --dry-run -o yaml > http-svc.yaml

3)測(cè)試訪問(wèn)
curl 10.1.95.78:8000

4)創(chuàng)建ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: httpd
namespace: default
spec:
rules:
- host: www.http123.com
http:
paths:
- path: /
backend:
serviceName: httpd
servicePort: 8000

5)綁定hosts,瀏覽器測(cè)試
也可以使用dns服務(wù)器,通過(guò)自建的dns服務(wù)器完成域名解析,從而避免頻繁的修改hosts文件
詳見(jiàn)輕量級(jí)域名解析服務(wù)器之dnsmasq

C:\Windows\System32\drivers\etc\hosts添加10.10.0.111 www.http123.com

總結(jié)
到此這篇關(guān)于k8s之ingress-nginx詳解和部署方案的文章就介紹到這了,更多相關(guān)ingress-nginx部署方案內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
kubernetes認(rèn)證鑒權(quán)內(nèi)容淺析
這篇文章主要為大家介紹了kubernetes認(rèn)證鑒權(quán)內(nèi)容淺析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-04-04
kubernetes 使用jq命令對(duì)資源配置查看方式
這篇文章主要介紹了kubernetes 使用jq命令對(duì)資源配置查看方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-11-11
k8s編排之StatefulSet知識(shí)點(diǎn)詳解一
這篇文章主要為大家介紹了k8s編排之StatefulSet知識(shí)點(diǎn)的部分詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-01-01
kubernetes部署dashboard及應(yīng)用小結(jié)
Dashboard?是基于網(wǎng)頁(yè)的?Kubernetes?用戶(hù)界面,可以對(duì)?Deployment?實(shí)現(xiàn)彈性伸縮、發(fā)起滾動(dòng)升級(jí)、重啟?Pod?或者使用向?qū)?chuàng)建新的應(yīng)用,這篇文章主要介紹了kubernetes部署dashboard,需要的朋友可以參考下2024-06-06
在Kubernetes集群中搭建Istio微服務(wù)網(wǎng)格的過(guò)程詳解
這篇文章主要介紹了在Kubernetes集群中搭建Istio微服務(wù)網(wǎng)格,我們采用default配置檔部署istio網(wǎng)格,istioctl?install命令不指定任何配置檔默認(rèn)就是呀default配置檔,需要的朋友可以參考下2022-05-05
k8s跨服務(wù)調(diào)用入門(mén)到實(shí)戰(zhàn)示例詳解
這篇文章主要為大家介紹了k8s跨服務(wù)調(diào)用入門(mén)到實(shí)戰(zhàn)示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-09-09
某集團(tuán)任意文件下載到虛擬主機(jī)getshell的方法
這篇文章主要介紹了某集團(tuán)任意文件下載到虛擬主機(jī)getshell的方法,非常不錯(cuò),具有參考借鑒價(jià)值,需要的朋友可以參考下2017-01-01
CentOS 7下YUM 本地倉(cāng)庫(kù)的搭建詳細(xì)步驟
這篇文章主要介紹了CentOS 7下YUM 本地倉(cāng)庫(kù)的搭建詳細(xì)步驟的相關(guān)資料,希望通過(guò)本文能幫助到大家實(shí)現(xiàn)這樣的功能,需要的朋友可以參考下2017-09-09
Kubekey安裝Kubernetes-1.24.8的詳細(xì)過(guò)程
這篇文章主要介紹了Kubekey安裝Kubernetes-1.24.8的詳細(xì)過(guò)程,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-05-05

