在容器領域內,Kubernetes已毋庸置疑成爲了容器編排和管理的社區標準。若是你但願你所搭建的應用程序能充分利用多雲(multi-cloud)的優點,有一些與Kubernetes網絡相關的基本內容是你必須瞭解與考慮的。python
Kubernetes中的基本管理單元並不是是一個容器,而是一個叫作pod的東西。咱們認爲部署了一個或多個容器的環境是一個pod單元。一般狀況下,它們表明了提供部分服務的單個功能端點。nginx
舉兩個有效的pods單元爲例:數據庫
pods具備如下經常使用的特性:api
Kubernetes服務位於負載均衡器以後,負責管理多個相同的pods。客戶端無需鏈接到每一個pod的IP,而是直接鏈接負載均衡器的IP地址。Kubernetes服務會將你的應用程序定義爲一個服務,使得Kubernetes能夠根據定義的規則和實際可用資源動態擴展pod數量。安全
若想要應用程序被Kubernetes基礎設施外部的客戶端訪問到,惟一的方法是將應用程序定義爲服務的一部分。不管你是否擴展節點,都須要Kubernetes服務分配外部IP地址。網絡
標籤是Kubernetes中一組做用於對象(如pods)的鍵值對,須要具備實際意義且有相關性。app
在Kubernetes的標準配置中,標籤並不直接影響與Kubernetes相關的核心操做,而是主要用於對對象的分組和識別。負載均衡
下面咱們將介紹一些Kubernetes推薦使用的網絡插件,這些插件用到了咱們上一節提到的標籤。利用標籤,它們能夠在容器運行時改變某些功能。在Kubernetes中,大多數使用的網絡插件都是基於容器網絡接口(Container Networking Interface ,CNI)規範,這項規範由Cloud Native Computing Foundation(CNCF)制定。CNI容許在多個容器平臺中使用相同的網絡插件。如今咱們使用一種調整網絡安全策略的方法,該方法並不像傳統的網絡或者安全團隊模型那樣預先設置好一切,而是在容器運行時,利用標籤來調整正確的網絡策略(容器的動態變化太過頻繁,很難進行手動干預),目前該方法已經成爲了 Kubernetes Network Special Internet Group(Network SIG)的一部分。現在,咱們已經有多個可供使用的網絡插件可以將網絡策略應用於命名空間和pods中,這其中包括OpenContrail 和 Project Calico。frontend
經過這種新方法,Kubernetes管理員能夠導入全部預先準備的策略,開發者負責調整並根據需求自主選擇策略,而全部這一切都會定義到pod中執行。spa
網絡策略示例:
POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/ { "kind": "NetworkPolicy", "metadata": { "name": "pol1" }, "spec": { "allowIncoming": { "from": [ { "pods": { "segment": "frontend" } } ], "toPorts": [ { "port": 80, "protocol": "TCP" } ] }, "podSelector": { "segment": "backend" } } }
有網絡策略定義的pod配置示例:
apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx segment: frontend spec: containers: - name: nginx image: nginx ports: - containerPort: 80
有了Kubernetes提供的功能,開發者如今擁有了徹底定義應用程序及其依賴性所需的靈活性,而且能夠在單個pod中使用多個容器。若是任何一個容器發生錯誤,Kubernetes可以確保將其對應的pod停用,自動用新的pod替換。此外,開發者還能夠定義應用程序或者服務偵聽的端口號,不管它是較大服務的一部分,或僅僅是一個獨立實例。經過這樣的操做,使用持續交付和部署方法論的快速開發和部署週期將會成爲常態。