K8s部署Nginx集群,通過Ingress實(shí)現(xiàn)HTTPS域名訪問過程
架構(gòu)
客戶端 → Ingress Controller (處理 TLS) → Service: nginx → Nginx Pod (提供靜態(tài)內(nèi)容)
service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
我們創(chuàng)建的 Service 類型默認(rèn)是 ClusterIP,Ingress 控制器可以通過 ClusterIP 訪問到 Pod。
secret存儲TLS證書
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=dong.nginx.com" kubectl create secret tls nginx-ssl-cert --cert=tls.crt --key=tls.key --namespace=default
ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
tls:
- hosts:
- dong.nginx.com
secretName: nginx-tls-secret
rules:
- host: dong.nginx.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx
port:
number: 80
在Ingress配置中,設(shè)置了注解?nginx.ingress.kubernetes.io/force-ssl-redirect: "true"?,這會導(dǎo)致Ingress控制器將HTTP請求重定向到HTTPS。
我們使用的是?kubernetes.io/ingress.class: "nginx"?,這通常是由NGINX Ingress控制器處理的。NGINX Ingress控制器默認(rèn)會監(jiān)聽80和443端口,并且當(dāng)你配置了TLS和強(qiáng)制重定向時(shí),80端口的請求會被重定向到443。
在host字段中指定了域名,需要通過域名才可以訪問(只有Host頭匹配的請求才會被路由到此服務(wù),如果直接訪問Ingress Controller的IP,由于缺少Host頭,請求不會被正確路由)。
訪問 ?HTTP? 端口 -> 被告知“請走 ?HTTPS?”
返回308永久重定向,說明HTTP被強(qiáng)制跳轉(zhuǎn)到HTTPS,這是常見的做法。服務(wù)器明確告訴客戶端:“你訪問的這個(gè) ?http? 地址已經(jīng)不再使用了,請永久地使用另一個(gè)地址(通常是 ?https? 地址)來訪問我。”這是現(xiàn)代Web服務(wù)的標(biāo)準(zhǔn)做法,為了安全,強(qiáng)制將不安全的 ?HTTP? 協(xié)議跳轉(zhuǎn)到安全的 ?HTTPS? 協(xié)議。
308 重定向需要客戶端(如瀏覽器)自動(dòng)跟隨重定向,但 curl 默認(rèn)不會自動(dòng)跟隨重定向。
Ingress Controller:處理 TLS 終止和路由
通常 Ingress 控制器會使用它自己的 TLS 證書,而 Pod 內(nèi)部的 nginx 不需要配置 SSL,可以只作為靜態(tài)文件服務(wù)器,因?yàn)?Ingress 控制器會處理 SSL 終止。
在Kubernetes中,通常訪問服務(wù)是通過Ingress控制器提供的入口。Ingress控制器會監(jiān)聽80和443端口(或者你配置的其他端口),然后根據(jù)Ingress規(guī)則路由流量。
configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
default.conf: |
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
autoindex off;
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 30d;
add_header Cache-Control "public";
}
}
在 ConfigMap 中,我們只配置了一個(gè) HTTP 服務(wù)器(監(jiān)聽 80 端口),并且沒有配置 SSL。因此,Pod 內(nèi)的 nginx 只會處理 HTTP 流量。而 Ingress 控制器會將 HTTPS 流量終止并轉(zhuǎn)發(fā)給 Service(即 Pod)的 80 端口。
nginx-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: html-pvc
spec:
storageClassName: nfs-client
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
存儲管理-PV動(dòng)態(tài)供給見–有狀態(tài)應(yīng)用-MySQL主從復(fù)制集群
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-web-cluster
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: config
mountPath: /etc/nginx/conf.d
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: config
configMap:
name: nginx-config
- name: html
persistentVolumeClaim:
claimName: html-pvc
用戶訪問
訪問前需要在用戶的主機(jī)上修改hosts文件進(jìn)行域名解析,添加:Ingress節(jié)點(diǎn)IP 及 域名。
通過Ingress節(jié)點(diǎn)IP地址(kubectl get ingress)加上Ingress控制器的Service上(kubectl get svc -n ingress-nginx)的暴露端口,用戶可以從集群外部訪問Ingress控制器。(這里需要通過域名訪問或者攜帶主機(jī)頭,如下:)
curl -H "Host:dong.nginx.com" https://192.168.1.73:31237 -k #證書是自簽名的,不在curl的CA信任庫中,需要通過-k或--insecure選項(xiàng)來跳過證書驗(yàn)證
當(dāng)前Ingress-controller的服務(wù)類型是NodePort,它會在每個(gè)節(jié)點(diǎn)上開放一個(gè)端口,所以訪問時(shí)必須帶上端口號。
1.http://dong.nginx.com:31441? → 308 重定向到 HTTPS
2.https://dong.nginx.com:31237? → Ingress → Service:nginx → Nginx Pod → 返回網(wǎng)頁內(nèi)容
curl默認(rèn)不會跟隨重定向。所以,當(dāng)您使用curl訪問HTTP時(shí),您看到的是308重定向的響應(yīng)體,而不是跟隨重定向后的內(nèi)容。
在瀏覽器中訪問http://dong.nginx.com:31441,瀏覽器會自動(dòng)重定向到HTTPS并顯示頁面,用戶不會看到308的頁面。
# 1. 查看重定向信息 curl -I http://dong.nginx.com:31441 # 2. 自動(dòng)跟隨重定向獲取最終內(nèi)容 curl -L http://dong.nginx.com:31441 # 3. 或者使用詳細(xì)模式查看整個(gè)過程 curl -v -L http://dong.nginx.com:31441
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
K8S?使用EFK日志的統(tǒng)一管理(詳細(xì)步驟)
在Kubernetes中,EFK是一種常見的日志統(tǒng)一管理方案,EFK堆棧允許你收集、存儲、搜素、分析和可視化容器應(yīng)用程序的日志,下面是如何在Kubernetes中使用EFK實(shí)現(xiàn)日志統(tǒng)一管理的詳細(xì)步驟,感興趣的朋友一起看看吧2025-01-01
kubernetes需要默認(rèn)的serviceaccount的原因解析
這篇文章主要介紹了kubernetes為何需要默認(rèn)的serviceaccount,ServiceAccount 是 Kubernetes 中的一種重要概念,它的實(shí)際使用場景包括很多,本文給大家講解的非常詳細(xì),需要的朋友可以參考下2023-04-04
Kubernetes應(yīng)用服務(wù)質(zhì)量管理詳解
這篇文章主要為大家介紹了Kubernetes應(yīng)用服務(wù)質(zhì)量管理詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11
K8S-ConfigMap實(shí)現(xiàn)應(yīng)用和配置分離詳解
這篇文章主要為大家介紹了K8S-ConfigMap實(shí)現(xiàn)應(yīng)用和配置分離詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-04-04
K8s?EphemeralContainer臨時(shí)容器解讀
Kubernetes臨時(shí)容器用于調(diào)試無shell容器,通過shareProcessNamespace參數(shù)實(shí)現(xiàn)安全登錄與故障排查,排查后可刪除,版本1.25及以上默認(rèn)啟用,需使用預(yù)裝debug工具的鏡像(如busybox)2025-08-08
詳解Rainbond內(nèi)置ServiceMesh微服務(wù)架構(gòu)
這篇文章主要為大家介紹了詳解Rainbond內(nèi)置ServiceMesh微服務(wù)架構(gòu),有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-04-04
k8s 中的 service 如何找到綁定的 Pod 及實(shí)現(xiàn) 
service 是一組具有相同 label pod 集合的抽象,集群內(nèi)外的各個(gè)服務(wù)可以通過 service 進(jìn)行互相通信,這篇文章主要介紹了k8s 中的 service 如何找到綁定的 Pod 以及如何實(shí)現(xiàn) Pod 負(fù)載均衡,需要的朋友可以參考下2022-10-10

