Kubernetes 若要把應用暴露於 Cluster 外部 ，已知可以使用 NodePort 和 LoadBlancer 類型的 Service，但當每暴露一個 Service 給外部時，就會需要暴露一個對應的 Port ，隨著 Service 越來越多之後，我們就需要管理更多的 Port Number，也會使得維運上更加複雜。這時就可以考慮使用 Kubernetes Ingress ，它可用來代理不同 Kubernetes Service，能對外開放統一的 Port ，並將外部的請求轉發到 Cluster 內不同的 Service 上，來實現負載均衡。 Ingress 專注於 Cluster 對外的暴露、負載均衡、L7轉發、 Virtual Hosting 等功能。
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 來求得答案。