kubernetes 可以創建多個 Pods,Pod 內有一個或多個 Container,那麼 Container 之間是怎麼溝通的的呢 ? 這裡歸類出一些 case :
- 不同網路下,不同 pod 間的 container 的通訊
- 同一網路下,不同 pod 間的 container 的通訊
- 同一個 pod 中,不同的 container 的通訊
以下來對這些 case 進行說明。

kubernetes 可以創建多個 Pods,Pod 內有一個或多個 Container,那麼 Container 之間是怎麼溝通的的呢 ? 這裡歸類出一些 case :
- 不同網路下,不同 pod 間的 container 的通訊
- 同一網路下,不同 pod 間的 container 的通訊
- 同一個 pod 中,不同的 container 的通訊
以下來對這些 case 進行說明。
Kubernetes 是可以支援
ClusterIP:Port
、PodIP:Port
的形式,來完成相互溝通的,但是這樣會帶來些問題,因為 Kubernetes 內部 Pod 和 Service 都有機會重啟的,這會導致 Pod 和 Service 的 IP 發生變化;但 Service 名字等一些標識資訊是不會經常變動的,所以 Kubernetes 更推薦通過 Service 的名字來訪問服務,這就是服務發現。Service Discovery 是一種機制,通過該機制,服務可以動態發現彼此,而無需 hardcode 硬寫 IP 或 endpoint 配置。可以讓我們只透過 Service 的名稱,就能找到相對應 Pod ,而非使用 IP 地址訪問。
Pod 的生命週期是動態的,因為 cluster 會根據需求,動態地創建或銷毀 Pod ,重啟的 Pod 自然也伴隨着 IP 地址的更動。為了解決這問題,kubernetes 在 客戶端和 Pod 間,引入了一個名為 Service 的組件,它會在 pod 的前方提供了一個穩定的網路端點。不只可以建立內部 Pod 之間的通信,讓 Pod 間可以用 domain name 的方式相互溝通;另外也可以建立外部與 Pod 的溝通管道。 最後 Service 也有能力爲這些 Pod 進行負載分配,平均每個 Pod 的使用率。
這題是 39. Combination Sum 的進階,給定一個 array 和 target ,找出 candidates 中所有可以使數字和為 target 的組合,但 candidates 中的每個數字,在每個組合中只能使用一次。對比 39. 中的數字是可以重複使用,這題是不能重複使用的,但兩題本質沒有區別,依然是使用 DFS 和 backtrack 思想求解。寫到現在其實已經有感覺到一定的模板了,但多多比較與其他 backtrack 題型的差異才是最重要的。
這題給了一個 array of distinct integer 以及目標總和 target , 求用此 array 來組成目標數字的所有組合。像這種要求返回所有符合要求解的題目,基本都是要利用到遞迴,類似的題目有 Subset 、 Permutation 、 Combination 等等,解題套路都是使用 DFS 和 Backtrack 來求得答案。
之前解題利用了交換 nums 裡面的兩個數字的方式,這次換另一種寫法,做出一個 inner list 收集可能的結果。基本解題思想都還是 Backtracking ,故把 leetcode46 和 leetcode47 重新解答一遍。
是經典的 46. Permutations 的進階版,現在數字會有重複(duplicate) 。這邊一樣使用 Backtrack 來求解。從數學上來說,
n
個 element ,且將相同的事物歸為一組, 可歸成 k 組, 且每組有m_i
個,其 Permutation 一共有n!/(m_1!m_2!...m_k!)
種排序,為高中數學題中,需要思考下的題目;用程式模擬這個過程也有難度,故被歸類在 Medium 等級。
是一道經典 distinct integers 的全排列問題,這邊使用 Backtrack 來求解。從數學上來說,n 個 element 的 Permutation 一共有 n! 種排序,思考起來算蠻簡單的,但要用程式模擬這個推導過程,卻是有點難度的,因此被歸類在 Medium 等級。
Backtrack 是 DFS 的一種形式,基本寫法類似於 TOP DOWN DFS,處理方式就是所謂的窮舉法,將所有可能的結果都找出來;每一個結果都實際看看這樣。換個角度來說,其實這個過程就如同在樹上遍歷 (Tree Traversal) ,而普通的 DFS 是不需要回溯狀態的。 Backtrack 強調了狀態回溯。
Workload 是指在 Kubernetes Pod 內運行的應用程式。但是 Pod 並不能保證總是可用的,所以需要管理它們。但若直接管理 Pod 的話,工作量將會非常大且繁瑣,為了減輕負擔,Kubernetes 提供 Workload Resources 來管理一組 Pods。即 Workload Resource 是 Kubernetes 中,定義和管理 Workload 的特定 API 物件,例如 Deployment、StatefulSet 等等都是屬於 Workload Resource。