k8s--集群內的pod調用集群外的服務

關于如何讓同一個局域網內的Kubernetes服務的Pod訪問同一局域網中的電腦上的服務。

可能的解決方案包括使用ClusterIP、NodePort、Headless Service、HostNetwork、ExternalIPs，或者直接使用Pod網絡。每種方法都有不同的適用場景，需要逐一分析。

例如，ClusterIP是默認的，只能在集群內部訪問，所以可能需要其他方式。NodePort會在每個節點上開放端口，用戶可以通過節點的IP訪問服務，但需要注意防火墻規則。HostNetwork讓Pod共享節點的網絡，可以直接訪問節點的IP，但可能有安全隱患。ExternalIPs允許服務綁定外部IP，但需要確保IP在集群節點上可用。直接使用Pod網絡的話，需要知道Pod的IP，但Pod重啟后IP會變，這可能不太穩定。

另外，用戶可能需要了解如何配置服務的Endpoints來指向外部服務的IP和端口，這樣可以通過Kubernetes的服務發現機制來訪問外部服務。這對于需要服務名解析的情況很有用，比如創建一個沒有選擇器的Service，然后手動定義Endpoints指向外部服務的地址。

還需要考慮網絡策略和防火墻的問題，確保Kubernetes集群的節點和外部服務的電腦之間的網絡是通的，端口沒有被防火墻阻止。如果使用Calico等網絡插件，可能需要調整網絡策略。

然后，用戶可能需要具體的步驟，比如如何創建Service和Endpoints，如何配置ExternalIPs或者HostNetwork。要給出示例的YAML配置，方便用戶參考。

另外，用戶可能不了解kube-proxy和網絡插件的工作原理，是否需要深入解釋？可能不需要太深入，但需要說明不同方法背后的原理，比如HostNetwork直接使用宿主機的網絡命名空間，ExternalIPs需要由kube-proxy管理。

最后，可能需要總結各個方法的適用場景，幫助用戶根據具體需求選擇。比如如果外部服務變動頻繁，使用Endpoints和Service可能更好；如果只是臨時測試，用HostNetwork或NodePort更簡單。

總結一下，我需要分步驟解釋各種方法，給出配置示例，并提醒需要注意的網絡連通性和安全問題。確保用戶能夠理解并選擇適合他們的方案。

要讓 Kubernetes 集群中的 Pod 訪問同一局域網內的外部服務（例如你的物理機或虛擬機上的服務），可以通過以下幾種方法實現。以下是具體步驟和注意事項：

方法 1：通過 Kubernetes Service 的 `ExternalName` 或手動 Endpoints

將外部服務抽象為 Kubernetes Service，使 Pod 通過 Service 名稱訪問外部服務。

步驟 1：創建指向外部服務的 Service

# external-service.yaml
apiVersion: v1
kind: Service
metadata:name: external-service
spec:type: ClusterIP  # 或 ExternalNameports:- protocol: TCPport: 80       # Service 監聽的端口targetPort: 8080  # 外部服務的端口
---
# 如果是手動指定 Endpoints（推薦）：
apiVersion: v1
kind: Endpoints
metadata:name: external-service
subsets:- addresses:- ip: 192.168.1.100  # 外部服務的局域網 IPports:- port: 8080         # 外部服務的端口

步驟 2：Pod 通過 Service 名稱訪問

在 Pod 中通過 external-service 這個 DNS 名稱訪問：

curl http://external-service:80

方法 2：直接通過局域網 IP 訪問

如果外部服務的 IP 是固定的，Pod 可以直接通過局域網 IP 訪問（需確保網絡策略允許）。

步驟 1：確認 Pod 網絡與局域網互通

? 確保 Kubernetes 集群的網絡插件（如 Calico、Flannel）允許 Pod 與外部網絡通信。
? 檢查防火墻規則是否放行流量（尤其是 Node 的防火墻）。

步驟 2：在 Pod 中直接訪問外部服務

curl http://192.168.1.100:8080

方法 3：使用 `HostNetwork` 模式

讓 Pod 共享宿主機的網絡命名空間，直接使用宿主機的 IP 和端口（慎用，存在安全隱患）。

步驟 1：配置 Pod 使用 HostNetwork

# pod.yaml
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:hostNetwork: true  # 共享宿主機網絡containers:- name: mycontainerimage: nginx

步驟 2：訪問外部服務

Pod 會直接使用宿主機的 IP（即 192.168.1.x），可以直接訪問同一局域網的服務。

方法 4：配置 `ExternalIPs`

將外部服務的 IP 綁定到 Kubernetes Service，通過 Service 訪問。

步驟 1：創建帶有 `externalIPs` 的 Service

# external-ip-service.yaml
apiVersion: v1
kind: Service
metadata:name: external-ip-service
spec:ports:- protocol: TCPport: 80targetPort: 8080externalIPs:- 192.168.1.100  # 外部服務的 IP

步驟 2：通過 Service 的 ExternalIP 訪問

在 Pod 中訪問 192.168.1.100:80，流量會被轉發到外部服務的 8080 端口。

方法 5：使用 NodePort 暴露外部服務

如果外部服務本身是 Kubernetes 集群外的服務，可以通過 NodePort 將流量轉發到外部 IP。

步驟 1：創建 NodePort Service

apiVersion: v1
kind: Service
metadata:name: nodeport-external-service
spec:type: NodePortports:- port: 80targetPort: 8080nodePort: 30000  # 手動指定 NodePort 范圍（默認 30000-32767）

步驟 2：通過任意節點的 IP + NodePort 訪問

在 Pod 中訪問 http://<任意節點IP>:30000，流量會通過 kube-proxy 轉發到外部服務。

關鍵注意事項

網絡策略：
? 確保 Kubernetes 節點的防火墻允許 Pod 與外部服務的通信。
? 如果使用網絡插件（如 Calico），檢查是否配置了允許出站流量的 NetworkPolicy。
DNS 解析：
? 如果外部服務有域名，確保 Pod 的 DNS 配置（如 /etc/resolv.conf）能解析該域名。
服務發現：
? 推薦使用方法 1（Service + Endpoints），因為可以利用 Kubernetes 的服務發現機制。
安全風險：
? 避免在生產環境使用 hostNetwork: true，可能導致端口沖突或安全漏洞。

總結

? 推薦方案：使用方法 1（Service + Endpoints）或方法 4（ExternalIPs），保持 Kubernetes 原生配置。
? 臨時測試：使用方法 3（HostNetwork）或直接通過 IP 訪問。

根據你的具體場景（如是否需要服務發現、是否允許直接暴露 IP）選擇最合適的方案。

異常：

我個人的場景是跑了一個后但服務的pod，但是數據庫，redis在我自己的電腦上，在公司我的電腦和集群的電腦是可以直接通信的，所以使用方法1來解決。但是似乎當我后端的pod重啟之后，給外部服務創建的endpoint的以下部分就沒有了

subsets:- addresses:- ip: 192.168.1.100  # 外部服務的局域網 IPports:- port: 8080         # 外部服務的端口

解決辦法：不要在service中加上selector

首先，用戶提到當手動創建Endpoints時，subsets下的地址和端口可能會消失。這可能涉及到幾個常見的問題。我需要回憶一下Kubernetes中Service和Endpoints的工作原理。Service通常由標簽選擇器（selector）自動關聯到Pod，生成對應的Endpoints。但當Service沒有selector時，用戶需要手動創建Endpoints，這正是用戶的情況，因為他們要指向外部IP。

可能的原因一：Endpoints的metadata.name是否與Service的名稱完全一致？Kubernetes通過名稱來關聯Service和Endpoints，如果名稱不匹配，Endpoints不會被正確關聯，導致Service沒有對應的Endpoints，因此subsets可能顯示為空或者被系統自動清理。
可能的原因二：是否有其他控制器或進程在修改Endpoints？例如，某些情況下，如果Service被錯誤地配置了selector，Kubernetes會嘗試自動管理Endpoints，覆蓋用戶手動創建的配置。用戶可能在創建Service時不小心添加了selector，導致系統自動生成Endpoints，覆蓋了手動配置。
可能的原因三：Endpoints的配置是否正確？比如縮進錯誤、端口定義不正確等YAML格式問題，可能導致Endpoints對象雖然被創建，但無法被正確識別，從而被系統忽略或刪除。
可能的原因四：是否存在其他資源沖突？例如，同名的Endpoints被其他資源管理，或者用戶誤刪了Endpoints對象。

在 Kubernetes 中，當通過 Service + Endpoints 方式將外部服務引入集群時，如果 Endpoints 中的 subsets 配置（如 IP 和端口）自動消失，通常是由以下原因導致的：

1. Service 意外配置了 Selector

如果 Service 中錯誤地配置了 selector 字段，Kubernetes 會認為該 Service 需要自動關聯 Pod，并嘗試根據 selector 自動生成和管理 Endpoints。此時手動創建的 Endpoints 會被系統覆蓋，導致 subsets 消失。

驗證方法：

kubectl describe service <service-name>

檢查輸出中是否有 Selector 字段。如果存在類似以下內容，說明配置錯誤：

Selector: app=my-app  # 非空表示 Service 關聯了 Pod

修復方法：

確保 Service 沒有 selector 字段：

apiVersion: v1
kind: Service
metadata:name: external-postgres
spec:ports:- protocol: TCPport: 5433targetPort: 5433# 注意：此處不能有 selector！

2. Endpoints 名稱與 Service 名稱不匹配

Kubernetes 要求 Endpoints 的 metadata.name 必須與 Service 的名稱完全一致，否則兩者無法關聯，導致手動創建的 Endpoints 失效。

驗證方法：

kubectl get endpoints <endpoints-name> -o yaml

檢查 metadata.name 是否與 Service 名稱一致。

修復方法：

確保 Endpoints 的 metadata.name 與 Service 名稱一致：

apiVersion: v1
kind: Endpoints
metadata:name: external-postgres  # 必須與 Service 名稱相同
subsets:- addresses:- ip: 10.210.200.77ports:- port: 5433

3. Endpoints YAML 格式錯誤

Endpoints 的 YAML 格式必須嚴格符合規范。常見的錯誤包括：
? 錯誤地在 Endpoints 中添加了 spec 字段（實際不需要）。
? subsets 的縮進或層級錯誤。

錯誤的配置示例：

apiVersion: v1
kind: Endpoints
metadata:name: external-postgres
spec:  # 錯誤！Endpoints 不需要 spec 字段subsets:- addresses:- ip: 10.210.200.77ports:- port: 5433

正確的配置：

apiVersion: v1
kind: Endpoints
metadata:name: external-postgres
subsets:  # 直接定義 subsets，無需 spec- addresses:- ip: 10.210.200.77ports:- port: 5433

4. 其他控制器或工具干擾

某些 Kubernetes 組件或第三方工具（如服務網格、監控組件）可能會監聽并修改 Endpoints。例如：
? Istio：如果啟用了自動 Sidecar 注入，可能會修改 Endpoints。
? Kubernetes 事件控制器：某些異常事件可能導致 Endpoints 被重置。

驗證方法：

檢查 Endpoints 的變更歷史：

kubectl get endpoints <endpoints-name> -o yaml --watch

修復方法：

? 如果使用了服務網格，檢查其文檔是否需要特殊配置。
? 通過 kubectl edit endpoints <name> 手動修復 subsets，觀察是否再次被修改。

5. 網絡策略或防火墻攔截

雖然與 Endpoints 配置無關，但如果 Kubernetes 節點無法訪問外部服務的 IP 和端口，某些網絡插件可能會錯誤地清理 Endpoints（極少見，但需排除）。

驗證方法：

在 Kubernetes 節點上測試外部服務的連通性：

# 在節點上執行
nc -zv 10.210.200.77 5433
nc -zv 10.210.200.77 6379

操作步驟總結

檢查 Service 是否配置了 Selector：

kubectl describe service external-postgres

檢查 Endpoints 名稱和格式：

kubectl get endpoints external-postgres -o yaml

重新應用正確的配置：

kubectl apply -f external-postgres.yaml

監控 Endpoints 變更：

kubectl get endpoints external-postgres -w

最終解決方案

如果以上步驟仍無法解決，提供一個完整的正確配置模板：

Service 定義（external-postgres.yaml）：

apiVersion: v1
kind: Service
metadata:name: external-postgres
spec:ports:- protocol: TCPport: 5433targetPort: 5433

Endpoints 定義（external-postgres-endpoints.yaml）：

apiVersion: v1
kind: Endpoints
metadata:name: external-postgres  # 必須與 Service 同名
subsets:- addresses:- ip: 10.210.200.77  # 外部服務 IPports:- port: 5433  # 外部服務端口

應用配置：

kubectl apply -f external-postgres.yaml
kubectl apply -f external-postgres-endpoints.yaml

關鍵驗證命令

? 查看 Service 和 Endpoints 是否關聯成功：

kubectl get svc,ep -l <service-name>

? 查看 Endpoints 詳細信息：

kubectl get endpoints external-postgres -o yaml

通過以上步驟，Endpoints 中的 subsets 應能正確持久化，不會自動消失。