Google Kubernetes Engine 簡稱是 GKE ，是一個由 Google 管理的 Kubernetes 開源容器編排平台的實現。因為 Kubernetes 的前身 Borg 本來就是 Google 內部的產品，憑藉著這樣的背景 GKE 號稱對於 Kubernetes 的支援跟擴展性跟其它雲端比起來會是最好的。對應其他的雲端服務是 :
- Amazon Web Services (AWS) : EKS
- Microsoft Azure : AKS
雲端化的 Kubernetes 簡單的說就是把可在地端原生的 Kubernetes 放到雲端上運行，由雲供應商幫助我們大幅簡化集群的設置管理與維運。由於只是讓雲供應商託管 Kubernetes ，最終差異也只是看雲供應商如何「預設」和「整合自己平台其他服務」至 Kubernetes 罷了，本質上 EKS、AKS、GKE 差異並不大，故基本上不推薦隨意更換 Kubernetes 服務的雲供應商或使用多雲，會考慮 GKE 的公司大多都是本來就在使用 GCP 雲端，更方便整合 Kubernetes 和 GCP 的各種服務。
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 的使用率。