是經典的 78. Subsets 的進階版，現在數字會有重複(duplicate)。這邊使用 Backtrack 模板來求解。這個題目還有要注意的地方，就是 array 不一定是順序的，例如 test case:
[4,4,4,1,4]，這範例在我們去除重複答案的時候，若沒注意到有亂序的可能性，高機率會出錯。
很經典的問題 : 冪集 the power set ，在數學上還蠻常見到的，理論上求得解答方式也很簡單，選或者不選排列組合，就可以得出答案。但在程式上要實現卻有一點點難度，故會被歸類到 Medium 等級。這邊使用 Backtrack 模板來解題。
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 的使用率。