目錄
- 1、ingress介紹
- 2、ingress的工作原理
- 3、ingress可以解決的問題
- 1)動態配置服務
- 2)減少不必要的端口暴露
- 4、部署ingress(deployment的方式)
- 1)配置文件準備(粘貼下面網址的yanl文件)
- 2)配置文件介紹和設置ingress的網絡模式
- 3)修改配置文件
- 4)拉取鏡像(通過查看ingress的yaml文件可以看出)和創建svc文件
- 5)指定運行節點(需要打標簽)
- 5、部署ingress(DaemonSet的方式)
- 1)添加hostNetwork
- 2)添加親和性屬性
- 3)設置節點的label
- 4)修改yaml文件(和deployment部署ingress的文件一樣,只需要修改此處即可)
- 4)執行并部署ingress
- 6、案例測試
- 1)創建deployment模板并修改
- 2)創建svc模板并修改
- 3)測試訪問
- 4)創建ingress
- 5)綁定hosts,瀏覽器測試
- 總結
本篇是基于k8s-v1.15.0版本,在現有集群上部署ingress。
1、ingress介紹
K8s集群對外暴露服務的方式目前只有三種:Loadblancer
;Nodeport
;ingress
前兩種熟悉起來比較快,而且使用起來也比較方便,在此就不進行介紹了。
下面詳細講解下ingress這個服務,ingress由兩部分組成:
- ingress controller:將新加入的Ingress轉化成Nginx的配置文件并使之生效
- ingress服務:將Nginx的配置抽象成一個Ingress對象,每添加一個新的服務只需寫一個新的Ingress的yaml文件即可
其中ingress controller目前主要有兩種:基于nginx服務的ingress controller
和基于traefik的ingress controller
。
而其中traefik的ingress controller
,目前支持http和https協議
。由于對nginx比較熟悉,而且需要使用TCP負載,所以在此我們選擇的是基于nginx服務的ingress controller。
但是基于nginx服務的ingress controller
根據不同的開發公司,又分為k8s社區的ingres-nginx
和nginx公司的nginx-ingress
。
在此根據github上的活躍度和關注人數,我們選擇的是k8s社區的ingres-nginx
。
k8s社區提供的ingress,github地址如下:https://github.com/kubernetes/ingress-nginx
nginx社區提供的ingress,github地址如下:https://github.com/nginxinc/kubernetes-ingress
2、ingress的工作原理
ingress具體的工作原理如下:
step1:ingress contronler通過與k8s的api進行交互,動態的去感知k8s集群中ingress服務規則的變化,然后讀取它,并按照定義的ingress規則,轉發到k8s集群中對應的service。
step2:而這個ingress規則寫明了哪個域名對應k8s集群中的哪個service,然后再根據ingress-controller中的nginx配置模板,生成一段對應的nginx配置。
step3:然后再把該配置動態的寫到ingress-controller的pod里,該ingress-controller的pod里面運行著一個nginx服務,控制器會把生成的nginx配置寫入到nginx的配置文件中,然后reload一下,使其配置生效,以此來達到域名分配置及動態更新的效果。
3、ingress可以解決的問題
1)動態配置服務
如果按照傳統方式, 當新增加一個服務時, 我們可能需要在流量入口加一個反向代理指向我們新的k8s服務. 而如果用了Ingress, 只需要配置好這個服務, 當服務啟動時, 會自動注冊到Ingress的中, 不需要而外的操作。
2)減少不必要的端口暴露
配置過k8s的都清楚, 第一步是要關閉防火墻的, 主要原因是k8s的很多服務會以NodePort方式映射出去, 這樣就相當于給宿主機打了很多孔, 既不安全也不優雅. 而Ingress可以避免這個問題, 除了Ingress自身服務可能需要映射出去, 其他服務都不要用NodePort方式。
4、部署ingress(deployment的方式)
1)配置文件準備(粘貼下面網址的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)配置文件介紹和設置ingress的網絡模式
1> namespace.yaml
創建一個獨立的命名空間 ingress-nginx。
2> configmap.yaml
ConfigMap是存儲通用的配置變量的,類似于配置文件,使用戶可以將分布式系統中用于不同模塊的環境變量統一到一個對象中管理;而它與配置文件的區別在于它是存在集群的“環境”中的,并且支持K8S集群中所有通用的操作調用方式。
從數據角度來看,ConfigMap的類型只是鍵值組,用于存儲被Pod或者其他資源對象(如RC)訪問的信息。這與secret的設計理念有異曲同工之妙,主要區別在于ConfigMap通常不用于存儲敏感信息,而只存儲簡單的文本信息。
ConfigMap可以保存環境變量的屬性,也可以保存配置文件。
創建pod時,對configmap進行綁定,pod內的應用可以直接引用ConfigMap的配置。相當于configmap為應用/運行環境封裝配置。
pod使用ConfigMap,通常用于:設置環境變量的值、設置命令行參數、創建配置文件。
3> default-backend.yaml
如果外界訪問的域名不存在的話,則默認轉發到default-http-backend這個Service,其會直接返回404。
4> rbac.yaml
負責Ingress的RBAC授權的控制,其創建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding。
5> with-rbac.yaml
是Ingress的核心,用于創建ingress-controller。前面提到過,ingress-controller的作用是將新加入的Ingress進行轉化為Nginx的配置。
6> 各文件的作用:
- configmap.yaml:提供configmap可以在線更新nginx的配置
- default-backend.yaml:提供一個缺省的后臺錯誤頁面 404
- namespace.yaml:創建一個獨立的命名空間 ingress-nginx
- rbac.yaml:創建對應的role rolebinding 用于rbac
- tcp-services-configmap.yaml:修改L4負載均衡配置的configmap
- udp-services-configmap.yaml:修改L4負載均衡配置的configmap
- with-rbac.yaml:有應用rbac的nginx-ingress-controller組件
3)修改配置文件
設置 hostNetwork: true
由于ingress 使用到物理機的80/443 端口,所以需要設置為hostNetwork模式
4)拉取鏡像(通過查看ingress的yaml文件可以看出)和創建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
創建svc:https://github.com/kubernetes/ingress-nginx/blob/master/deploy/baremetal/service-nodeport.yaml
5)指定運行節點(需要打標簽)
nginx-ingress-controller會隨意選擇一個node節點運行pod,為此需要我們把nginx-ingress-controller運行到指定的node節點上
首先需要給需要運行nginx-ingress-controller的node節點打標簽,在此我們把nginx-ingress-controller運行在指定的node節點上
kubectl get nodes –show-labels #先查看各個node上的lables信息 kubectl label nodes node3 nginx=nginx #給node3打標簽 kubectl get nodes –show-labels #查看node3上的lables
修改ingress的yaml文件中的標簽
5、部署ingress(DaemonSet的方式)
官方原始文件使用的是deployment,replicate 為 1,這樣將會在某一臺節點上啟動對應的nginx-ingress-controller pod。外部流量訪問至該節點,由該節點負載分擔至內部的service。測試環境考慮防止單點故障,改為DaemonSet然后刪掉replicate ,配合親和性部署在制定節點上啟動nginx-ingress-controller pod,確保有多個節點啟動nginx-ingress-controller pod,后續將這些節點加入到外部硬件負載均衡組實現高可用性。
1)添加hostNetwork
true:添加該字段,暴露nginx-ingress-controller pod的服務端口(80)
2)添加親和性屬性
增加親和性部署,有custom/ingress-controller-ready 標簽的節點才會部署該DaemonSet
3)設置節點的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)執行并部署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: Container
kubectl apply -f mandatory-deamon.yaml kubectl get ds -n ingress-nginx kubectl get pod -n ingress-nginx -o wide
注意:大家可能會想node2上也打了標簽,為什么node2上沒有;原因很簡單,我的node2是master,已經有了污點的標簽,從親和性上就已經不再容忍任何pod運行到master上,所以只能看到node3和node4上有nginx-ingress的pod。
6、案例測試
1)創建deployment模板并修改
kubectl create deployment httpd --image=www.my.com/web/httpd:latest --dry-run -o yaml > http-dep.yaml
2)創建svc模板并修改
kubectl expose deployment httpd --port=8000 --target-port=80 --type=ClusterIP --dry-run -o yaml > http-svc.yaml
3)測試訪問
curl 10.1.95.78:8000
4)創建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,瀏覽器測試
也可以使用dns服務器,通過自建的dns服務器完成域名解析,從而避免頻繁的修改hosts文件
詳見輕量級域名解析服務器之dnsmasq
C:\Windows\System32\drivers\etc\hosts添加10.10.0.111 www.http123.com