目錄
一、前端頁面顯示?503 Service Temporarily Unavailable
問題背景
解決方案
原理
二、Dockfile 構(gòu)建鏡像失?。篧hen using COPY with more than one source file, the destination must be a directory and end with a /?
問題背景
解決方案
原理
三、前端頁面顯示 502 Bad Gateway
問題背景?
解決方案
原理
一、前端頁面顯示?503 Service Temporarily Unavailable
時(shí)間：2023-04-19? ? ? ? k8s 版本：v1.18.4
問題背景
????????Kubernetes 中的前端項(xiàng)目 Pod 運(yùn)行正常，但訪問通過 Ingress 代理的域名時(shí)頁面出現(xiàn)“503 Service Temporarily Unavailable”的錯(cuò)誤，查看 log 日志也無報(bào)錯(cuò)信息。
解決方案
????????我最初是 service.yaml 和 ingress.yaml 里的 name 名稱為 gtp，然后我又修改為 gpt，在修改前沒 kubectl delete 原來的資源，當(dāng)我刪除原來的為 gtp 名稱的 ingress 和 service 資源后，前端頁面就可以正常訪問了。
原理
????????問題出在修改資源名稱時(shí)未刪除舊資源。當(dāng)我將名稱從 gtp 修改為 gpt 時(shí)，應(yīng)該首先使用 kubectl delete 刪除舊的資源（即原先的 Ingress 和 Service），然后再應(yīng)用新的資源配置。如果沒有刪除舊資源，可能會(huì)導(dǎo)致以下問題：
-
Ingress 混淆：如果舊的 Ingress 和新的 Ingress 都存在，它們可能會(huì)爭奪同一個(gè)域名和路徑。這可能導(dǎo)致 Ingress 控制器在處理請(qǐng)求時(shí)混淆，從而選擇錯(cuò)誤的后端服務(wù)。當(dāng)你刪除了舊的 Ingress 資源后，Ingress 控制器開始將流量正確路由到新的后端服務(wù)。
-
后端服務(wù)沖突：類似地，如果舊的 Service 和新的 Service 都存在且監(jiān)聽相同的端口，可能會(huì)導(dǎo)致端口沖突或 Kubernetes 無法正確將流量路由到預(yù)期的后端服務(wù)。刪除舊的 Service 資源后，Ingress 控制器可以將流量路由到正確的后端服務(wù)。
????????總之，當(dāng)你修改資源名稱時(shí)，務(wù)必確保先刪除舊資源，以避免出現(xiàn)混淆和沖突。在應(yīng)用新的資源配置之前，使用 kubectl delete 刪除舊資源，然后再使用 kubectl apply 應(yīng)用新資源配置。這樣可以確保 Ingress 控制器將流量正確路由到新的后端服務(wù)。
二、Dockfile 構(gòu)建鏡像失敗：When using COPY with more than one source file, the destination must be a directory and end with a /?
問題背景
????????COPY 根據(jù)通配符 * 匹配到多個(gè)多個(gè)文件，所以語法錯(cuò)誤，鏡像構(gòu)建不成功，push 到鏡像倉庫失敗。?
解決方案
在 COPY 最后面加個(gè) / 即可。
原理
? ?COPY 指令的語法是 COPY <src> <dest>，其中 <src> 是要復(fù)制的源文件或目錄，<dest> 是目標(biāo)路徑。在這個(gè)例子中，. 表示當(dāng)前目錄，所以 COPY . . 的含義是將構(gòu)建上下文的當(dāng)前目錄中的所有文件和目錄復(fù)制到容器的工作目錄（由 WORKDIR 指令設(shè)置）。
與?COPY target/*.jar . 有以下幾點(diǎn)區(qū)別：
-
COPY . .是將整個(gè)構(gòu)建上下文的當(dāng)前目錄的內(nèi)容復(fù)制到容器的工作目錄。而COPY target/*.jar .僅復(fù)制target目錄下所有的.jar文件到容器的工作目錄。 -
COPY . .不需要指定目標(biāo)路徑以/結(jié)尾，因?yàn)樗窃趯⒄麄€(gè)目錄復(fù)制到另一個(gè)目錄。而COPY target/*.jar .復(fù)制多個(gè)文件時(shí)需要以/結(jié)尾，表示目標(biāo)是一個(gè)目錄。
????????使用哪種 COPY 取決于您的需求。如果您需要將整個(gè)構(gòu)建上下文的所有文件復(fù)制到容器中，可以使用 COPY . .。如果您只需要復(fù)制特定的文件或目錄，可以使用類似 COPY target/*.jar . 的語法。
三、前端頁面顯示 502 Bad Gateway
時(shí)間：2023-08-3? ? ? ? k8s 版本：v1.25.4
問題背景?
? ? ? ? 新建了個(gè) service 資源類型為 nodePort 后端指定一組 pod 標(biāo)簽，service 創(chuàng)建成功；使用 Nginx 代理了這個(gè) nodePort 端口使外部可以訪問，結(jié)果訪問前端頁面顯示??502 Bad Gateway。
解決方案
1. 查看 Nginx 錯(cuò)誤日志：
2023/08/03 15:01:52 [error] 29229#29229: *1116307 connect() failed (111: Connection refused) while connecting to upstream, client: 10.22.11.237, server: valetorder.xxx.com, request: "GET / HTTP/1.1", upstream: "http://10.0.4.173:31193/", host: "valetorder.uat.dusto-yc.com"
2023/08/03 15:01:52 [error] 29229#29229: *1116307 connect() failed (111: Connection refused) while connecting to upstream, client: 10.22.11.237, server: valetorder.xxx.com, request: "GET / HTTP/1.1", upstream: "http://10.0.4.172:31193/", host: "valetorder.uat.dusto-yc.com"????????初步排查是否后端服務(wù)器（upstream）正常運(yùn)行，并且監(jiān)聽了配置文件中指定的端口（例如：31193）
2. 查看后端 pod 的運(yùn)行狀態(tài)
是 running 狀態(tài)，無異常
3.?判斷 service 與指定的 pod 是否關(guān)聯(lián)了
[root@idc-master-01 yaml]# kubectl describe svc -n uat valet-order-uat-out
Name: valet-order-uat-out
Namespace: uat
Labels: app.kubernetes.io/name=valet-order-uat
io.cattle.field/appId=valet-order-uat
Annotations: <none>
Selector: app=valet-order-uat
Type: NodePort
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.102.177.78
IPs: 10.102.177.78
Port: http 80/TCP
TargetPort: 80/TCP
NodePort: http 31193/TCP
Endpoints: <none>
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
[root@idc-master-01 yaml]# kubectl get pods --selector app=valet-order-uat -n uat
No resources found in uat namespace.Endpoints 為空且查找不到有?app=valet-order-uat 標(biāo)簽的 pod，那就是 service 資源有問題。
4. 修改 service 資源中的 selector 字段的值
指定 pod 資源文件如下：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: valet-order-uat
vvv: 1.0.1
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app.kubernetes.io/name: valet-order-uat????????我在 service 中的 selector 選擇了?app: valet-order-uat 標(biāo)簽，導(dǎo)致沒有匹配到，改為?app.kubernetes.io/name: valet-order-uat 即可。
最終頁面成功訪問。
原理
? ? ? ? 上面 Pod 資源中的 spec.selector.matchLabels 使用的是一個(gè)復(fù)合標(biāo)簽，即 app.kubernetes.io/name: valet-order-uat。而在 Service 資源中的 selector 使用的是簡單的單個(gè)標(biāo)簽 app: valet-order-uat。
????????由于標(biāo)簽的匹配規(guī)則是精確匹配，所以 Service 的 selector 并不會(huì)與 Pod 資源的 spec.selector.matchLabels 完全匹配。因此，Service 將不會(huì)與該 Pod 直接關(guān)聯(lián)，且不會(huì)將流量導(dǎo)向該 Pod。
????????當(dāng) Pod 資源中的 metadata.labels 和 spec.selector.matchLabels 同時(shí)打了不同的標(biāo)簽，Service 將只會(huì)根據(jù) spec.selector.matchLabels 來選擇與之關(guān)聯(lián)的 Pod。
????????在 Kubernetes 中，Service 的 selector 字段用于選擇與之關(guān)聯(lián)的 Pod。selector 字段包含一個(gè)標(biāo)簽鍵值對(duì)的 map，其中定義了 Service 要選擇哪些標(biāo)簽的 Pod 與之關(guān)聯(lián)。而 Pod 的 metadata.labels 字段是用來標(biāo)識(shí) Pod 的特性和屬性的標(biāo)簽。文章來源：http://www.zghlxwxcb.cn/news/detail-433538.html
????????當(dāng) Service 創(chuàng)建或更新時(shí)，它會(huì)根據(jù) spec.selector.matchLabels 字段的標(biāo)簽鍵值對(duì)來選擇與之匹配的 Pod。Pod 的 metadata.labels 字段中的標(biāo)簽不會(huì)影響這個(gè)選擇過程。文章來源地址http://www.zghlxwxcb.cn/news/detail-433538.html
到了這里，關(guān)于K8s 生產(chǎn)環(huán)境問題匯總及解決方案（持續(xù)更新 ing）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
