共計 2534 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要介紹“Kubernetes 中容器到容器通信是怎樣的”，在日常操作中，相信很多人在 Kubernetes 中容器到容器通信是怎樣的問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kubernetes 中容器到容器通信是怎樣的”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
Kubernetes 是一個容器化的解決方案。它提供了 Pods 的運行時環(huán)境，該環(huán)境可以容納一個或多個容器。Kubernetes 的一個重要方面是 Pod 內的容器通信。
此外，管理 Kubernetes 網絡的一個重要領域是在內部和外部轉發(fā)容器端口，以確保 Pod 中的容器之間能夠正確通信。為了管理此類通信，Kubernetes 提供以下四種聯網模型：
容器到容器通信 Pod 到 Pod 通信 Pod 到 Service 通信對外通信容器之間的通信
在單個 Pod 中擁有多個容器，要使它們彼此之間進行通信變得相對簡單，可以使用幾種不同的方法來做到這一點。在本文中，我們將詳細討論兩種方法：共享卷和進程間通信。
1. Kubernetes Pod 中的共享卷
在 Kubernetes 中，你可以使用共享的 Kubernetes 卷，作為在 Pod 中的容器之間共享數據的簡單有效的方法。在大多數情況下，Pod 中所有容器共享使用主機上的目錄就足夠了。
Kubernetes Volumes 使數據能夠在容器重啟后幸免于難，但是這些卷具有與 Pod 相同的生存期。這意味著卷（及其存儲的數據）與 Pod 存在的時間完全一樣。如果出于任何原因刪除了該 Pod，即使創(chuàng)建了相同的替換，共享卷也將被破壞并從頭開始創(chuàng)建。
具有共享卷的多容器 Pod 的標準用例是，一個容器將日志或其他文件寫入共享目錄，而另一個容器從共享目錄讀取。例如，我們可以像這樣創(chuàng)建一個 Pod：
apiVersion: v1kind: Podmetadata: name: mc1spec: volumes: - name: html emptyDir: {} containers: - name: 1st image: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html - name: 2nd image: debian volumeMounts: - name: html mountPath: /html command: [ /bin/sh , -c] args: - while true; do date /html/index.html; sleep 1; done
在此示例中，我們定義了一個名為 html 的卷。它的類型為 emptyDir，這意味著該卷是在將 Pod 分配給節(jié)點時首次創(chuàng)建的，并且只要該 Pod 在該節(jié)點上運行就存在。顧名思義，它最初是空的。第一個容器運行 Nginx 服務器，并將共享卷安裝到目錄 /usr/share/nginx/html。第二個容器使用 Debian 鏡像，并將共享卷安裝到目錄 / html。第二個容器每秒將當前日期和時間添加到共享卷中的 index.html 文件中。
當用戶向 Pod 發(fā)出 HTTP 請求時，Nginx 服務器將讀取此文件并將其傳回給用戶。
你可以通過暴露 nginx 端口并使用瀏覽器訪問它，或通過直接在容器中檢查共享目錄來檢查 Pod 是否正常工作：
$ kubectl exec mc1 -c 1st -- /bin/cat /usr/share/nginx/html/index.html ...
$ kubectl exec mc1 -c 2nd -- /bin/cat /html/index.html ...2. 進程間通信（Inter-Process Communications，IPC）
Pod 中的容器共享相同的 IPC 名稱空間，這意味著它們還可以使用標準的進程間通信，例如 SystemV 信號量或 POSIX 共享內存相互通信。容器使用本地主機名的策略在 Pod 中進行通信。
在下面的示例中，我們定義了具有兩個容器的 Pod。兩者都使用相同的 Docker 鏡像。第一個容器是生產者，它創(chuàng)建一個標準的 Linux 消息隊列，寫一些隨機消息，然后寫一個特殊的退出消息。第二個容器是使用者，它打開相同的消息隊列以讀取消息，直到接收到退出消息為止。我們還將重啟策略設置為“從不”，因此在兩個容器終止后，容器停止。
apiVersion: v1kind: Podmetadata: name: mc2spec: containers: - name: producer image: allingeek/ch7_ipc command: [./ipc , -producer] - name: consumer image: allingeek/ch7_ipc command: [./ipc , -consumer] restartPolicy: Never
要檢查這一點，請使用 kubectl create 創(chuàng)建 pod 并觀察 Pod 的狀態(tài)：
$ kubectl get pods --show-all -wNAME READY STATUS RESTARTS AGEmc2 0/2 Pending 0 0smc2 0/2 ContainerCreating 0 0smc2 0/2 Completed 0 29
現在，你可以檢查每個容器的日志，并驗證第二個容器是否收到了第一個容器的所有消息，包括退出消息：
$ kubectl logs mc2 -c producer...Produced: f4Produced: 1dProduced: 9eProduced: 27
$ kubectl logs mc2 -c consumer...Consumed: f4Consumed: 1dConsumed: 9eConsumed: 27Consumed: done
但是，此 Pod 存在一個主要問題，它與容器的啟動方式有關。
到此，關于“Kubernetes 中容器到容器通信是怎樣的”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注丸趣 TV 網站，丸趣 TV 小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
