Virtual Private Cloud 虛擬私有雲網路,簡寫為 VPC、網路、VPC Network、Network 等等都可以,是 Google 使用 Andromeda(/ænˈdrɑː.mə.də/) 網路虛擬化技術實現的一個雲端資源,提供如 GCP-VM、GKE、Serverless Workloads 或 App Engine 等等雲端服務的「網路功能」,能讓 User 高自由度的建立管理和優化網路架構。對應其他的雲端服務是 :
- Amazon Web Services (AWS) : Amazon VPC
- Microsoft Azure : Azure Virtual Network
GCP-VPC 和 AWS-VPC 架構上蠻不一樣的,GCP-VPC 是全球性的,只要在同一個 GCP-VPC 內,就算不同 Region 也能使用 Internal IP ; 但如果是不同的 GCP-VPC 就算在同一個 Region 下也不能互相通訊。而 AWS-VPC 是針對 Region 來設計的,故 AWS-VPC 只要跨 Region 就不是內網無法直接溝通,需再多做其他設定才能連線到彼此。
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 的使用率。
無類別域間路由( Classless Inter-Domain Routing ,簡稱 CIDR )是為了避免造成 IP 位址的大量浪費,於是出現的一種技術。CIDR重點有:
- 多變長度子網路遮罩 (Variable-Length Subnet Mask,VLSM)
- 路由匯總 (Route Summarization)(暫不介紹)