☰

避免 pod 環境變數與 Docker 樣式連結衝突

tag-icon • tag-icon kubernetes environment-variables
避免 pod 環境變數與 Docker 樣式連結衝突

我們使用 Docker 作為容器運行時在 Kubernetes 中運行或元件。它的一個問題是 pod 環境被 Docker 風格的連結變數污染，例如

  • SERVICENAME_PORT_8181_TCP
  • SERVICENAME_PORT_HTTP
  • ……
  • SERVICENAME_PORT

對於每個可見服務（同一命名空間中的服務）。在這種情況下，自動建立的變數很容易與明確聲明的環境發生衝突。這有時會導致難以診斷的問題。我也不想依賴這些自動變量，因為我希望容器不依賴 Kubernetes 服務配置的詳細資訊。目前，我正在為顯式變數添加唯一的名稱前綴以避免此類衝突。

有沒有辦法將叢集配置為不為每個可見服務新增這些自動變數？或者，使用其他運行時可以containerd解決這個問題嗎？令我驚訝的是，沒有可用谷歌搜尋的解決方案，因為透過環境變數進行配置被認為是一種很好的做法。一般來說，我如何使用環境而不遇到此類命名衝突？或者服務名稱被視為容器合約的一部分，我不應該隨意更改它們？

答案1

有沒有辦法將叢集配置為不為每個可見服務新增這些自動變數？

是和否：據我所知，不是集群範圍內的，而是enableServiceLinks: false領域在spec:旨在讓您可以將其關閉

或者，使用其他運行時（例如containerd）可以解決這個問題嗎？

不，這些名稱是本著與 docker 相容的精神添加的，但與 docker 根本無關——它們是由 kubelet 注入

一般來說，我如何使用環境而不遇到此類命名衝突？或者服務名稱被視為容器合約的一部分，我不應該隨意更改它們？

另一種選擇是，您也可以直接屏蔽它們，而不是大規模禁止它們具體的那些打擾你的應用程式的；以結尾的那些_HTTP對於 Spring Boot 尤其有問題，其中有一個Servicewhometadata: { name:是一些超級通用名稱，例如serviceorserver

您可以在每個部署中執行此操作：

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

或者您可以聲明一個包含攻擊性配置的 ConfigMap 並批量覆蓋它們envFrom:（以便不必修補每個受影響的部署）

相關內容