Kubernetes 1.2 新功能解析：multizone（多區）支持

seal_de 發布于2019-07-01 16:21 / 2947人閱讀

摘要：只有谷歌的和亞馬遜的目前被自動的支持盡管通過給節點和數據卷安排添加適當的標簽來給其他云或者裸機加入類似的支持很容易。當建立持久數據卷時，管理控制器自動會把標簽加給數據卷。因為數據卷都不能跨區，這意味著只能被創建在和數據卷同區內。

導論

Kubernetes 1.2增加的一個新的功能是把一個集群跑在多個failure zone里（谷歌GCE管它叫“zone”，亞馬遜AWS管它們叫“availability zones”，這里我們統稱它們為“zones”）。這是把多個K8S集群聯合起來（被稱為“Ubernetes”）的一個輕便的版本。Ubernetes會允許把在多個云或者不同地區的多個K8S集群聯合起來。然而，很多開發者近是簡單地想把他們云上地K8S集群跑在不同zone里，這就是K8S的1.2版本所提供的multizone（多區）支持（我們稱之為“Ubernetes Lite”）。

K8S 1.2特意對多區支持做了一些限制：一個簡單的K8S集群可以跑在多區，但只能是在同一個地區（和同一個云上）。只有谷歌的GCE和亞馬遜的AWS目前被自動的支持（盡管通過給節點和數據卷安排添加適當的標簽來給其他云或者裸機加入類似的支持很容易）。

功能

當節點啟動之后，kubelet自動給它們添加zone信息的標簽。K8S會自動在單個區的單個集群的冗余控制器（RC）內平均分布pods或者在節點上分布服務（來減少失敗帶來的影響）。對于多區集群來說，這種平均分布的行為也應該是跨區（來減少區掛掉的影響）。（這是通過SelectorSpreadPriority來實現的）。這是最理想的方式，但如果你集群所在的zone是不同的（比如，節點數量不同，節點類型不同或者不同的節點資源要求），這些都會有可能導致無法完美的跨區平均分布pods。如果可以的話，你可以使用同一個區（同樣的節點數量和節點類型）來減少不平均分配的概率。
當建立持久數據卷時，PersistentVolumeLabel管理控制器自動會把zone標簽加給數據卷。調度器（通過VolumeZonePredicate）會確保pod和分配給這個pod的數據卷在同一個zone里，因為數據卷不能跨區。

限制

對于多區支持有如下幾個限制

我們假定不同的區互相距離很近，所以我們不做任何路由。尤其，通過服務過來的請求可能是跨區的（即使在一些pods里的pod是支持這些服務的且這些pods和client同區），這可能會導致額外的延遲和開銷。

數據卷對區有粘性，只能以PersistentVolume來工作，比如說如果你特地在pod的參數里指定一個EBS數據卷是無法奏效的。

集群不能跨云跨地區（這個功能要靠K8S完整版的集群聯合支持）。

盡管你的節點在多個區，kube-up現在默認是跑一個單一的master node。盡管服務是高可用，能在一個區內容忍一些損失，控制層是在某個單一區內。需要高可用控制層的開發者需留意關于K8S高可用方面的指南。

代碼梳理

現在來梳理一下如何在GCE和AWS上建立和使用一個多區集群。你需要建一個完整的集群（指定MULTIZONE=1）,然后通過再跑kube-up在其他區增加節點（設定KUBE_USE_EXISTING_MASTER=true）

1. 建立你的集群

和往常一樣來建立集群，傳入MULTIZONE讓集群知道去管理多區，在us-central1-a里創建節點:
GCE:

curl -sS https://get.k8s.io | MULTIZONE=1 KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-aNUM_NODES=3 bash

AWS:

curl -sS https://get.k8s.io | MULTIZONE=1 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash

通過這步就常規建立了一個集群，仍然在單區跑（但通過 MULTIZONE=1 賦予了多區的能力）

2 節點打標簽

看下節點，你能看到它們被打了zone信息的標簽。它們目前都在us-central1-a (GCE) 或者在 us-west-2a (AWS) 。這些標簽，對地區來說，是failure-domain.beta.kubernetes.io/region ；對zone來說是 failure-domain.beta.kubernetes.io/zone

3 在第二個區內再加一些節點

現在讓我們在一個不同的zone內（us-central1-b 或者 us-west-2b）利用已有的master，在現有的集群里再加入一些節點。我們可以再跑一下kube-up，但如果指定KUBE_USE_EXISTING_MASTER=1 的話，kube-up不會創建一個新的master，但會重復使用之前已有的。

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh

在AWS上我們也需要給子網指定網絡CIDR，和master內部的IP地址：
KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh

這時候再看下節點，應該增加了三個節點，在us-central1-b里。

4 數據卷和zone的粘性

通過新的動態數據卷創建來創立一個數據卷（只有持久數據卷才能保證數據卷和zone的粘性）

持久數據卷也被打了標簽，標明了它被創建的地區和zone。在K8S 1.2版本里，動態的持久數據卷總是被建在集群master同區（在現在這個例子里，是在us-centaral1-a / us-west-2a）；這在完整版中會提高。
所以，現在我們要來創建一個pod，來使用持久數據卷。因為GCE PDS/AWS EBS數據卷都不能跨區，這意味著pod只能被創建在和數據卷同區內。

5 Pods跨區的分布

在冗余控制器（RC）里的pod或者服務會被自動地跨區分布。首先，讓我們在第三個區內再生成一些節點

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh

AWS:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh

檢查一下你在三個區里有節點：

kubectl get nodes --show-labels

建立一個K8S教程里guestbook-go例子，包含一個RC，數量寫3，跑一個簡單的web應用：

find kubernetes/examples/guestbook-go/ -name "*.json" | xargs -I {} kubectl create -f {}

pods應該跨三個區分布：

負載均衡器在一個集群之內跨區，在K8S標準教程guestbook-go里有這個負載均衡器服務的例子:

負載均衡器目前指向所有的pods，盡管它們在不同的區里。

6 關閉集群

結束之后，清理一下
GCE:

KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh

AWS:

KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh

原文鏈接點這里

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/32447.html

Kubernetes 1.3 中一些隱藏的功能

摘要：到現在為止，部署有狀態應用比如分布式數據庫已經是一個棘手的問題，但是其實也不是做不到。我們也會展示如何在本地更加輕松地部署分布式數據庫在我們與客戶目前正在積極處理的區域內。伴隨著5000多次的提交，以及大約350位貢獻者在社區以及該行業的貢獻，Kubernetes現在已經到1.3版本了，已于上周發布！網址：點這里。 Kubernetes的首次發布要追溯到兩年前。這個項目的社區參與度和...

kk_miles 2019-07-01 16:24 評論0 收藏0
在GKE上面創建你的第一個Kubernetes集群

摘要：創建你的谷歌云項目如果你還沒有谷歌賬號，那么在你繼續步驟之前先創建一個。一個集群包括了由谷歌和一套節點主導的服務器。點擊查看完美結語我們今天帶大家一起來看了一下谷歌云平臺，開啟計費功能，打開相關，然后在上面創建一個集群。你可能已經了解過Kubernetes和Google云平臺，但是可能還并沒有真正創建過一個集群。在這里，我們會帶領大家梳理一些基礎知識，跟著這個教程一步步來，你就會自己...

Jonathan Shieber 2019-07-01 16:21 評論0 收藏0
Kubernetes 1.2 新功能解析：ConfigMap (上)

摘要：我們希望能夠讓應用的開發者在里充分使用這樣的模式。盡管允許類似于驗證信息和秘鑰這些信息從應用當中分離，但在過去并沒有為了普通的或者非配置而存在的對象。從數據角度來看，的類型只是鍵值組。容器的配置管理——把應用的代碼和配置區分開，是一個好的操作。我們希望能夠讓應用的開發者在Kubernetes里充分使用這樣的模式。盡管Secrets API允許類似于驗證信息和秘鑰這些信息從應用當中分離...

李濤 2019-07-01 16:20 評論0 收藏0
Kubernetes 1.2 新功能解析：ConfigMap (下)

摘要：的工作就是為作出的修改查看我們的配置文件，并且運行讀取配置文件的新版本回調函數，使用設置新的。它的目標是使任意額外的成為一個單獨更新的，這樣我們只要執行一次回調函數。 Kubernetes 1.2版本添加了一個叫ConfigMap的新功能。這個功能提供給容器注入應用程序數據的方式。注入配置文件對于大部分應用程序來說很強大，但是新的ConfigMap功能不僅可以在容器開啟時提供初始配置功...

Blackjun 2019-07-01 16:22 評論0 收藏0
Kubernetes 1.2 新功能解析：ConfigMap (中)

摘要：使用很多應用程序的配置需要通過配置文件，命令行參數和環境變量的組合配置來完成。舉個例子，思考以下的我們可以像這樣在一個中來使用這個的鍵當這個運行的時候，它的輸出將包括以下幾行使用案例用設置命令行參數也可以被使用來設置容器中的命令或者參數值。使用ConfigMap 很多應用程序的配置需要通過配置文件，命令行參數和環境變量的組合配置來完成。這些配置應該從image內容中解耦，以此來保持容...

honmaple 2019-07-01 16:22 評論0 收藏0