近萬字案例文：Rancher + VMware PKS實現全球數百站點的邊緣K8S集羣管理

時間 2019-11-08

標籤萬字案例 rancher vmware pks 實現全球數百站點邊緣 k8s 集羣管理欄目虛擬機简体版

原文原文鏈接

Sovereign Systems是一家成立於2007年的技術諮詢公司，幫助客戶將傳統數據中心技術和應用程序轉換爲更高效的、基於雲的技術平臺，以更好地應對業務挑戰。曾連續3年提名CRN，而且在2012年到2016年均被評爲美國增加最快的私營公司之一。
本文由Sovereign Systems的解決方案架構師Chip Zoller根據客戶的使用案例撰寫而成。

Rancher是一個容器編排管理平臺，它已經在這一領域深耕幾年而且具有不少簡單易用的實用功能。近幾年，它通過重構已經徹底擁抱Kubernetes。在本文中，我將着重介紹如何在VMware Enterprise PKS之上構建一個企業級、高可用和安全的Rancher Server安裝。同時，我將回答「爲何要在PKS上使用Rancher」這一問題。此外，本文將包括整個構建流程、架構以及完整的安裝指南。涉及的內容十分豐富，趕忙開始吧！nginx

把Rancher部署在PKS上？

我知道這並非一個廣泛的搭配，特別是這兩個解決方案還存在某種競爭關係。它們都可以在不一樣的雲提供商部署Kubernetes集羣，並能夠在本地部署到諸如vSphere之類的堆棧。它們分別都有本身的長處和短處，可是在管理空間中二者沒有重疊的地方。Enterprise PKS使用BOSH部署Kubernetes集羣，而且繼續將其用於生命週期的事件——擴展、修復、升級等。而Rancher則是將本身的驅動程序用於各類雲PaaS解決方案，甚至使用vSphere進行本地部署來執行相似的任務。但Rancher可以導入外部配置的集羣而且爲其提供可見性，至今PKS尚未實現這樣的功能。而在VMware 2019大會上，VMware宣佈推出一款名爲Tanzu Mission Control的產品，該產品在將來或許能實現Rancher現有的這些功能。可是，在那以前，Rancher依舊錶明着優秀的技術，它能夠管理而且聚合不一樣的Kubernetes集羣到單一的系統中。json

這個案例從何而來？

和我以前寫過的不少文章同樣，這篇文章也是從客戶項目中衍生出來的。並且因爲找不到關於這個主題的Enterprise PKS指南，我決定本身寫一個。這個客戶計劃使用裸機、小型硬件將在邊緣的Kubernetes部署到全球數百個站點。他們須要將全部集羣統一到一個工具中，從而方便管理、監控以及應用程序部署。他們在主要的數據中心運行Enterprise PKS，來爲其餘業務需求部署Kubernetes集羣。因爲這些站點都與他們在世界各地的各個數據中心相鏈接，所以它們須要彙集在一個能夠在本地運行的工具中，同時必須具備高可用性、安全性和高性能。將Enterprise PKS用於底層、專用的Kubernetes集羣，而後在該集羣上以HA模式在Rancher Server上分層，這樣操做爲咱們兩個方面的絕佳功能——經過NSX-T進行網絡和安全性，經過BOSH進行集羣生命週期維護，經過Harbor複製鏡像倉庫而且經過Rancher在邊緣範圍內對分散的Kubernetes集羣在單一窗格進行統一管理。api

架構

咱們先來看看架構圖。瀏覽器

理論上說，咱們在底部有一個vSphere棧，它在咱們本地的SDDC中託管這個環境。接下來，咱們經過PKS構建了一個3-master和3-worker的Kubernetes集羣。除了許多其餘系統容器（未在上圖顯示）以外，worker還託管Rancher pod和Nginx pod。基於以上，咱們使用NSX-T提供的負載均衡器來提供兩個主要虛擬的服務器：一個用於控制平面訪問，另外一個用於ingress訪問。安全

然而，通過反覆的試驗並最終失敗以後，我發現NSX-T的L7負載均衡器並不支持Rancher正常運行所需的必要請求頭。具體來講，Rancher須要在HTTP請求中傳遞4個請求頭到pod。這些請求頭用於識別入站請求的來源，並確保在應用程序外部已經發生適當的TLS終止。其中一個請求頭X-Forwarded-Proto，它能夠告訴Rancher用於與負載均衡器進行通訊的協議，但NSX-T的負載均衡器沒法傳遞這些請求頭。基於此，咱們必須使用第三方ingress controller——nginx，它是目前最流行的解決方案之一，它對大部分的客戶端選項提供了普遍的支持，而且能夠直接發送請求頭。bash

咱們接着往下一個層次看，進入Kubernetes內部（以下圖所示）。請記住，咱們正在專門研究worker，但正在抽象化諸如節點之類的物理層。服務器

外部請求經過Nginx controller中的LoadBalance服務類型進入集羣。從該服務構建的端點列表中選擇一個nginx controller，進而匹配ingress controller中的規則。該請求將轉發到Rancher Service，最後到與該服務上的標籤selector匹配的pod。網絡

咱們接下來一步一步完成安裝過程，看完以後你將會有更深的理解。架構

安裝

請記住上文提到的架構，咱們將開始將這些碎片拼在一塊兒。一共有6個大步驟，每一個步驟下都有詳細的小步驟，我會詳細說明。app

一、配置新的自定義PKS集羣

第一步，咱們將專門爲Rancher制定一個plan，而後構建一個專門用於在HA模式下運行Rancher的集羣。咱們還將製做一個自定義的負載均衡器配置文件，以供構建中參考。

二、使用Helm準備集羣

集羣構建完成以後，咱們須要進行準備，以即可以使用Helm的軟件包，由於咱們將使用它來安裝ingress controller和Rancher。

三、生成證書和secret

這是一個企業級的部署，這意味着要使用自定義證書。因此咱們須要建立那些證書而且使它們可供Kubernetes的各類API資源使用。

四、建立並配置Ingress

既然咱們沒法使用NSX-T做爲Ingress controller，那麼咱們必須配置另外一種類型並適當地配置它。而後咱們將使用一個NSX-T的Layer-4負載均衡器來發送流量到ingress。

五、安裝Rancher

接下來，咱們使用Helm安裝Rancher。

六、配置基礎架構

一切都就位以後，咱們須要執行一些部署後的配置任務，而後才完成全部的步驟。

接下來，我將詳細解釋每個步驟具體如何操做。

配置新的自定義PKS集羣

首先咱們須要作的是設置PKS基礎架構，以便咱們能夠將Kubernetes集羣部署在任意地方。須要作兩件最基礎的事情：建立一個新plan，建立中型負載均衡器。咱們的plan須要指定3個master以使控制平面級別高可用，而且3個worker在工做負載級別高可用。在本例中，因爲咱們正在準備將大量集羣安裝到Rancher中，所以咱們可能要繼續進行操做，並指定一箇中型負載均衡器，不然PKS會給咱們一個很小的負載均衡器。這個負載均衡器將爲控制平面/API訪問提供虛擬服務器並將traffic發送到Rancher。

在PKS tile中，我使用如下配置建立一個新plan。

根據你本身的需求來建立plan，但記住master和worker的數量。若是想要將其放入生產環境中，我建議你增長master永久磁盤的規格。既然每一個主節點都是一個包含控制平面組件和etcd的組合節點，而且Rancher將充分利用Kubernetes集羣的etcd安裝做爲其數據存儲，所以咱們要確保有足夠的空間。

你可使用底部的附加組件部分來自動加載任意Kubernetes Manifest，使其能夠在集羣構建過程當中運行。我將使用pks-dns，它能夠在控制平面啓動後自動爲其建立DNS記錄。若是你以前還沒有使用過，我強烈建議你試用一下。

最後，爲了讓Rancher agent可以正確運行，請務必在此集羣上啓動「容許特權」模式。

如今，使用以前保存的plan和提交的更改，你應該可以運行一個pks plans而且顯示這個新的plan。

$ pks plans
Name         ID                                      Description
dev-small    8A0E21A8-8072-4D80-B365-D1F502085560    1 master; 2 workers (max 4)
dev-large    58375a45-17f7-4291-acf1-455bfdc8e371    1 master; 4 workers (max 8)
prod-large   241118e5-69b2-4ef9-b47f-4d2ab071aff5    3 masters; 10 workers (20 max)
dev-tiny     2fa824527-318d-4253-9f8e-0025863b8c8a   1 master; 1 worker (max 2); auto-adds DNS record upon completion.
rancher      fa824527-318d-4253-9f8e-0025863b8c8a    Deploys HA configuration with 3 workers for testing Rancher HA builds.
複製代碼

有了這個，咱們如今能夠建立一個自定義負載均衡器plan。目前，實現這個方法的惟一方式是經過pks CLI工具或經過建立自定義JSON規範文件建立API。保存一下信息到名爲lb-medium.json.的文件中，根據本身的需求替換「name」和」description」的值。

{
      "name": "lb-medium",
      "description": "Network profile for medium NSX-T load balancer",
      "parameters": {
             "lb_size": "medium"
     }
}
複製代碼

運行如下命令來建立一個新的網絡配置文件：

$ pks create-network-profile lb-medium.json
複製代碼

再次檢查，確保plan是存在的。

$ pks network-profiles

Name        Description
lb-medium   Network profile for medium NSX-T load balancer
複製代碼

如今使用你的plan和中型負載均衡器建立一個新的PKS集羣。

$ pks create-cluster czpksrancher05 -e czpksrancher05.sovsystems.com -p rancher --network-profile lb-medium
複製代碼

構建集羣將會花費幾分鐘的時間，能夠趁機休息一下。你能夠監視集羣建立過程，以瞭解何時建立完成。

$ watch -n 5 pks cluster czpksrancher05

Every 5.0s: pks cluster czpksrancher05

Name:                     czpksrancher05
Plan Name:                rancher
UUID:                     3373eb33-8c8e-4c11-a7a8-4b25fe17722d
Last Action:              CREATE
Last Action State:        in progress
Last Action Description:  Instance provisioning in progress
Kubernetes Master Host:   czpksrancher05.sovsystems.com
Kubernetes Master Port:   8443
Worker Nodes:             3
Kubernetes Master IP(s):  In Progress
Network Profile Name:     lb-medium
複製代碼

集羣建立完成以後，若是你以前使用了我推薦的pls-dns工具，那麼你的DNS記錄如今也應該已經建立好了。

$ nslookup czpksrancher05
Server:     10.10.30.13
Address:    10.10.30.13#53
Name:    czpksrancher05.sovsystems.com

Address: 10.50.0.71
複製代碼

如今，全部必要的工做都完成了，咱們能夠訪問這個集羣。首先讓咱們先配置kubeconfig。

$ pks get-credentials czpksrancher05
複製代碼

而後確認咱們是否具備訪問權限。

$ kubectl cluster-info
Kubernetes master is running at https://czpksrancher05.sovsystems.com:8443
CoreDNS is running at https://czpksrancher05.sovsystems.com:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
複製代碼

使用Helm準備集羣

既然如今咱們已經能夠訪問咱們的集羣，我須要使用Helm來準備它。Helm是一個用chart的打包格式來將整個應用程序部署到Kubernetes的一個工具。這些chart打包了完整部署應用程序所需的各類Kubernetes manifest。網絡上已經有大量的文章介紹了Helm及其入門，因此我將再也不贅述。我假設你已經瞭解了這些，並將Helm二進制文件添加到了PATH中。咱們須要在Kubernetes建立一個必要的對象，以供Tiller（Helm的服務器端組件）運行。這包括了一個ServiceAccount、ClusterRoleBinding，而後初始化Helm。

$ kubectl -n kube-system create serviceaccount tiller
serviceaccount/tiller created
複製代碼

建立Tiller賬戶的綁定做爲集羣管理員。當你完成安裝以後，你就能夠解除綁定了。一般來講，綁定service account到集羣管理員角色並非一個好主意，除非它們真的須要集羣範圍的訪問。若是你想的話，能夠限制Tiller部署到單個命名空間中。幸運的是，在Helm3中將不會有Tiller，這將進一步簡化Helm chart的部署並提升了安全性。

$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller created
複製代碼

接下來，使用service account初始化Helm，這將在kube-system命名空間建立一個Tiller pod。

$ helm init --service-account tiller
$HELM_HOME has been configured at /home/chip/.helm. 
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
複製代碼

你如今應該可以檢查並看到一個新的Tiller pod已經建立完成而且正在運行。

$ kubectl -n kube-system get po -l app=helm
NAME                             READY     STATUS     RESTARTS    AGE
tiller-deploy-5d6cc99fc-sv6z6    1/1       Running    0           5m25s
複製代碼

helm version要能確保客戶端的helm二進制文件可以與新建立的Tiller pod通訊。

$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
複製代碼

第二個步驟就完成，接下來咱們須要作一些證書工做。

生成證書和secret

如今，咱們不得不建立咱們的自定義證書並使它們可供Kubernetes使用。在本例中，我使用由內部企業證書頒發機構（CA）簽名的證書，可是你能夠只使用由第三方根簽名的通用證書。Rancher可使用以上兩種證書，也可使用自簽名證書。因爲這是一個企業級部署，咱們須要一個已經創建的信任鏈，所以咱們將使用企業CA。

建立證書的過程可能會有所不一樣，所以我沒法一一列出全部狀況，我只會簡單介紹與本例所需證書建立和生成過程相同的證書。可是不管如何，咱們都須要一個主機名，經過它能夠訪問集羣中運行的Rancher應用程序。不要將以前咱們在建立PKS集羣時使用的外部主機名混淆，它們時兩個單獨的地址，而且做用也不同。我將這個Rancher安裝命名爲「czrancherblog」，以便正確地生成並簽名個人證書。

經過Internet的魔力，咱們能夠快速完成生成過程，直到得到證書，secret和根CA證書文件。

確保運行kubectl的系統能夠訪問這些文件，而後繼續。

咱們將爲Rancher建立一個新的命名空間，在命名空間內，咱們須要建立2個secret：一個用於簽署咱們的主機證書的根CA證書，以及實際生成的證書及其對應的私鑰。

$ kubectl create ns cattle-system
namespace/cattle-system created
複製代碼

在建立第一個secret以前，確保根CA證書命名爲cacerts.pem，必須準確地使用這個名字，不然Rancher pod將啓動失敗。

$ kubectl -n cattle-system create secret generic tls-ca --from-file=cacerts.pem
secret/tls-ca created
複製代碼

接下來，建立TLS secret，該secret將保存czrancherblog站點的主機證書。此外，在下一步建立的nginx ingress controllerPod也會須要這個secret，以便正確認證客戶請求。

$ kubectl -n cattle-system create secret tls czrancherblog-secret --cert=czrancherblog.cer --key=czrancherblog.key
secret/czrancherblog-secret created
複製代碼

驗證已經建立的兩個secret

$ kubectl -n cattle-system get secret
NAME                    TYPE                                    DATA     AGE
czrancherblog-secret    kubernetes.io/tls                       2        2m7s
default-token-4b7xj     kubernetes.io/service-account-token     3        5m1s
tls-ca                  Opaque                                  1        3m26s
複製代碼

你會注意到，建立了這些secret，實際上只是建立兩種不一樣類型的secret而已。tls-ca這個secret是Opaque類型的secret，而czrancherblog-secret是一個TLS secret。若是你兩相比較，你會注意到tls-ca secret會在數據部分爲cacerts.pem列出一個base64-encoded 證書。而czrancherblog-secret 將會列出其中的兩個，每一個文件分配一個。你同時還會注意到不管你提供哪一種輸入文件，都已經爲tls.crt和tls.key列出它們的值（通過base64編碼以使它們模糊以後）。

如今咱們已經完成證書的生成了，如今應該到nginx ingress的部分。

建立和配置Ingress

既然secret和命名空間都已經建立，如今讓咱們來安裝nginx-ingress controller。如上文所提到的，儘管Enterprise PKS能夠而且將使用NSX-T做爲現成的Ingress controller，可是Rancher有些特殊需求是這一controller沒法知足的。所以在這一狀況下，咱們將使用其餘的controller。Nginx有一個被普遍使用而且技術成熟的ingress controller，剛好符合咱們的需求。請注意在本例中，我使用的是kubernetes/ingress-nginx，而不是nginxinc/Kubernetes-ingress。儘管它們有些許差別，但其實在本例中二者都能使用。

在您的終端上，運行如下Helm命令以從穩定版本中安裝kubernetes / ingress-nginx controller：

helm install stable/nginx-ingress --name nginx --namespace cattle-system --set controller.kind=DaemonSet
複製代碼

在這個命令中，咱們讓Helm把nginx對象放入cattle-system命名空間中，而且將pod做爲DaemonSet而不是Deployment來運行。咱們但願每一個Kubernetes節點都有一個controller，進而節點故障不會消除通往Rancher Pod的入口數據路徑。Rancher將完成相似的任務，但將使用具備pod反關聯規則的deployment（這與vSphere DRS的工做原理類似）。

命令完成以後，你將會從Helm得到一連串的返回，包括全部它建立的對象。須要指出的是，幾個API對象是ConfigMap，它存儲nginx controller的配置以及服務。

==> v1/Service
NAME                                  TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
nginx-nginx-ingress-controllern       LoadBalancer   10.100.200.48   <pending>     80:32013/TCP,443:32051/TCP   0s
nginx-nginx-ingress-default-backend   ClusterIP      10.100.200.45   <none>        80/TCP                       0s
複製代碼

第一個稱爲nginx-nginx-ingress-controller的類型爲LoadBalancer。從應用程序的角度來看，這實際上將是Rancher集羣的切入點。若是你看到External-IP欄，你將會注意到它最初只報告了<pending>狀態。這時候須要給你的Kubernetes集羣一些時間來拉取鏡像，而後再次檢查命名空間的服務。

# kubectl -n cattle-system get svc
NAME                                 TYPE          CLUSTER-IP      EXTERNAL-IP                  PORT(S)                       AGE
nginx-nginx-ingress-controller       LoadBalancer  10.100.200.48   10.50.0.79,100.64.128.125    80:32013/TCP,443:32051/TCP    6m35s
nginx-nginx-ingress-default-backend  ClusterIP     10.100.200.45   <none>                       80/TCP                        6m35s
複製代碼

這一次，你將會發現它分配了兩個IP，由於NSX容器插件（NCP）注意到該對象的建立，並已與NSX-T進行通訊，以使用爲此集羣指定的中型負載均衡器爲咱們建立新的虛擬服務器。

若是你跳到NSX-T管理器界面中的Server Pool選項卡，並找到此處引用的選項卡，那麼能夠檢查Pool Member選項卡，並查看它已自動添加了該服務引用的端點。

Name欄被截斷了，可是IP欄依舊可見。讓咱們再次檢查一下Kubernetes。

$ kubectl -n cattle-system get po -o wide -L app
NAME                                                  READY    IP            NODE                                    APP
nginx-nginx-ingress-controller-wjn2x                  1/1      10.11.54.2    9aa90453-2aff-4655-a366-0ea8e366de4a    nginx-ingress
nginx-nginx-ingress-controller-wkgms                  1/1      10.11.54.3    f35d32a0-4dd3-42e4-995b-5daffe36dfee    nginx-ingress
nginx-nginx-ingress-controller-wpbtp                  1/1      10.11.54.4    e832528a-899c-4018-8d12-a54790aa4e15    nginx-ingress
nginx-nginx-ingress-default-backend-8fc6b98c6-6r2jh   1/1      10.11.54.5    f35d32a0-4dd3-42e4-995b-5daffe36dfee    nginx-ingress
複製代碼

輸出的內容被稍微修改了一點點，去除了沒必要要的欄，但除了正在運行的節點以外，你還能夠清晰地看到pod、它們的狀態以及IP地址。

有了新虛擬服務器的IP地址，咱們接下來須要建立一個DNS記錄，能夠與咱們的Rancher HA安裝的主機名對應。我決定將其命名爲「czrancherblog」，所以我將在DNS中建立一個A記錄，將在czrancherblog指向10.50.0.79。

$ nslookup czrancherblog
Server:         10.10.30.13
Address:        10.10.30.13#53 
Name:    czrancherblog.sovsystems.com
Address: 10.50.0.79
複製代碼

這一階段的最後一步是在Kubernetes上建立ingress controller。儘管咱們已經有LoadBalancer這一服務類型，咱們依舊須要ingress資源來路由流量到Rancher service。但該服務尚不存在，但很快就能夠建立。

使用如下代碼建立一個新的manifest，命名爲ingress.yaml，而且使用kubectl create -f ingress.yaml對其進行應用：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  namespace: cattle-system
  name: rancher-ingress
spec:
  rules:
  - host: czrancherblog.sovsystems.com
    http:
      paths:
        - backend:
            serviceName: rancher
            servicePort: 80
  tls:
  - hosts:
    - czrancherblog.sovsystems.com
    secretName: czrancherblog-secret
複製代碼

如今我來解釋一下這個manifest。首先，咱們的類型是Ingress，接下來咱們有一個註釋。這一行實際上在作兩件事：指示NCP不要告訴NSX-T建立和配置任何對象，並告訴Nginx controller將流量路由到端口80上還沒有建立的名爲rancher的服務。最後，當來自主機值爲czrancherblog.sovsystems.com的請求中的任何流量進入系統時，它使用咱們建立的包含證書及密鑰的TLS secret應用到controller上。

儘管咱們但願不會出錯，可是咱們仍然要將該地址放入網絡瀏覽器中，以查看返回的內容。

咱們將得到一些重要的信息。首先，很是明顯的大字「503 Service Temporarily Unavailable」，考慮到目前尚無流量通過nginx controller，這樣的返回結果是符合指望的。其次，在地址欄咱們看到了一個綠色鎖的圖標，這意味着咱們建立的包含證書的TLS secret已經被接受而且應用於主機規則。

到目前爲止，都在向預想的方向進行，讓咱們進行下一步。

安裝Rancher

終於到了期待已久的一刻——安裝Rancher。如今咱們一切都準備好了，開始安裝吧！

添加Rancher stable倉庫到Helm，而後進行更新並拉取最新chart。

$ helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
"rancher-stable" has been added to your repositories
複製代碼

$ helm repo list
NAME              URL
stable            https://kubernetes-charts.storage.googleapis.com
local             http://127.0.0.1:8879/charts
rancher-stable    https://releases.rancher.com/server-charts/stable
複製代碼

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "rancher-stable" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.
複製代碼

爲何在安裝nginx ingress以前咱們不須要添加一個倉庫呢？由於那個chart實際上來自由谷歌託管的默認」stable」倉庫，所以沒有自定義倉庫能夠添加。對於Rancher，咱們必須添加stable或latest倉庫以訪問其管理的chart。

若是你已經成功更新了，那麼趕忙激活Rancher吧。從stable repo中安裝最新的chart，並檢查輸出。

$ helm install rancher-stable/rancher --name rancher --namespace cattle-system --set hostname=czrancherblog.sovsystems.com --set ingress.tls.source=secret --set privateCA=true 

NAME:    rancher
LAST DEPLOYED: Sun Sep 8 18:11:18 2019
NAMESPACE: cattle-system
STATUS: DEPLOYED

RESOURCES:
==> v1/ClusterRoleBinding
NAME     AGE
rancher  1s 

==> v1/Deployment
NAME      READY   UP-TO-DATE  AVAILABLE  AGE
rancher   0/3     0           0          1s 

==> v1/Pod(related)
NAME                       READY    STATUS              RESTARTS    AGE
rancher-6b774d9468-2svww   0/1      ContainerCreating   0           0s
rancher-6b774d9468-5n8n7   0/1      Pending             0           0s
rancher-6b774d9468-dsq4t   0/1      Pending             0           0s 

==> v1/Service
NAME      TYPE        CLUSTER-IP       EXTERNAL-IP    PORT(S)    AGE
rancher   ClusterIP   10.100.200.15    <none>         80/TCP     1s 

==> v1/ServiceAccount
NAME      SECRETS   AGE
rancher   1         1s 

==> v1beta1/Ingress
NAME       HOSTS                 ADDRESS   PORTS      AGE
rancher    czrancherblog.sovsystems.com    80, 443    1s
 
NOTES:
Rancher Server has been installed. 

NOTE: Rancher may take several minutes to fully initialize. Please standby while Certificates are being issued and Ingress comes up. 

Check out our docs at https://rancher.com/docs/rancher/v2.x/en/ 

Browse to https://czrancherblog.sovsystems.com

Happy Containering!
複製代碼

很好，如今chart爲咱們部署了大量的Kubernetes對象。然而，注意一下最後一個對象，它是另外一個ingress。咱們不須要它，因此直接將其刪除。

$ kubectl -n cattle-system delete ing rancher
ingress.extensions "rancher" deleted
複製代碼

檢查pod以確保它們如今正在運行。

$ kubectl -n cattle-system get po -l app=rancher
NAME                        READY      STATUS     RESTARTS    AGE
rancher-6b774d9468-2svww    1/1        Running    2           5m32s
rancher-6b774d9468-5n8n7    1/1        Running    2           5m32s
rancher-6b774d9468-dsq4t    1/1        Running    0           5m32s
複製代碼

很是棒，一切都起來了。若是你在RESTARTS列中看到的值不是零，也不要驚慌，Kubernetes最終會與其controller和監控循環保持一致，所以只要採起適當的措施，就可使得實際狀態達到所需狀態爲止。

如今，這些工做都完成以後，讓咱們再次檢查咱們的網頁，看看發生了什麼。

正如咱們所但願的那樣，咱們如今進入咱們的Rancher集羣了！讓咱們設置初始密碼以及在下一頁面中設置server URL。若是不進行設置，它將自動填充咱們的主機名。

這一步驟就算完成啦，接下來讓咱們進入最後一步。

配置基礎架構

既然咱們已經讓一切都起來了而且正在運行，讓咱們作些事情。

首先，你可能已經注意到你的「local」集羣卡在Provisioning的狀態，正在等待設置主機名。一般這幾分鐘以後就會自動解決，但在本例中，則須要執行幾個簡單的步驟。

最快的修復步驟是點擊最右邊的設置按鈕來編輯這個集羣。

如今不作任何更改，直接點擊保存。

而後回到主頁，它應該已經起來了。

再次進入集羣，確保你的節點正在彙報狀態。

接下來，咱們須要在主機之間分配咱們的基礎PKS Kubernetes節點。若是你的plan包括多個可用空間，你可能已經完成這一步了。但若是你像我同樣，沒有多個可用空間，你將須要某種方法來確保你的master和你的worker分佈在ESXi主機上。若是你據說過個人Optimize-VMwarePKS項目，我強烈建議你使用它，該項目能夠自動爲你處理master，但咱們依舊須要手動把worker分開。請記住，咱們不只須要API和控制平面的高可用，咱們也須要Rancher 數據平面的高可用。這意味着任何管理程序的故障都不會影響咱們應用程序的可訪問性。

你使用-ProcessDRSRules標誌運行Optimize-VMware-PKS以後，它應該檢測到該集羣的master並建立DRS反關聯性規則。如今，你須要爲worker節點手動建立一個新的節點。

爲worker建立一個新的反關聯規則，並添加全部規則。因爲BOSH會使用UUID而不是實際名稱來部署它們，所以在列表中找到它們十分困難，可是你能夠在vSphere VM和模板清單視圖中找到它們（若是你使用-ProcessDRSRules標誌運行Optimize-VMware-PKS），或者你能夠在引用部署後，從BOSH CLI獲取名稱。

$ bosh -d service-instance_3373eb33-8c8e-4c11-a7a8-4b25fe17722d vms
Using environment 'czpcfbosh.sovsystems.com' as client 'ops_manager' 

Task 55540. Done 

Deployment 'service-instance_3373eb33-8c8e-4c11-a7a8-4b25fe17722d' 

Instance                                     Process State   AZ    IPs         VM CID                                    VM Type      Active
master/00be5bab-649d-4226-a535-b2a8b15582ee  running         AZ1   10.50.8.3   vm-a8a0c53e-3358-46a9-b0ff-2996e8c94c26   medium.disk  true
master/1ac3d2df-6a94-48d9-89e7-867c1f18bc1b  running         AZ1   10.50.8.2   vm-a6e54e16-e216-4ae3-8a99-db9100cf40c8   medium.disk  true
master/c866e776-aba3-49c5-afe0-8bf7a128829e  running         AZ1   10.50.8.4   vm-33eea584-ff26-45ed-bce3-0630fe74f88a   medium.disk  true
worker/113d6856-6b4e-43ef-92ad-1fb5b610d28d  running         AZ1   10.50.8.6   vm-5508aaec-4253-4458-b2de-26675a1f049f   medium.disk  true
worker/c0d00231-4afb-4a4a-9a38-668281d9411e  running         AZ1   10.50.8.5   vm-e4dfc491-d69f-4404-8ab9-81d2f1f4bd0d   medium.disk  true
worker/ff67a937-8fea-4c13-8917-3d92533eaade  running         AZ1   10.50.8.7   vm-dcc29000-16c2-4f5a-b8f4-a5420f425400   medium.disk  true 

6 vms

Succeeded
複製代碼

不管你選擇哪一種方法，只要能保證規則建立便可。

如今你已經有了master和worker的反關聯規則，那麼請確保你在多個方面都具有高可用性。若是你願意進行測試，那麼讓工做節點（或與此相關的主節點）發生故障，或刪除Rancher Pod，而後查看Kubernetes建立的新pod。此時，Rancher應該還保持工做狀態。

結語

你已經看到了咱們如何從零開始建立了一個具有高可用性以及完整功能的Rancher Server，而且你也應該採起了一些措施確保將其安全地分佈在底層架構上。你須要牢記一個重要的考慮因素：當在Enterprise PKS上運行Rancher的時候，與Kubernetes命名空間有關。當在Kubernetes上安裝Rancher時，經過建立CRD和其餘對象，Rancher從平臺的角度將與Kubernetes深度集成。當用戶建立一個新項目或導入一個新集羣時，Kubernetes將會在後臺建立一個新的命名空間。在其餘Kubernetes環境中，這樣的操做流程會很是完美，但在Enterprise PKS中，一個新的命名空間則意味着新的Tier-1 router、新的邏輯網段、新的pod IP塊等。在PKS沒有預先設置好的狀況下，若是大量導入集羣和建立項目，那麼這些命名空間很快會耗盡諸如pod IP塊之類的NSX-T對象。若是你正在考慮在生產環境中採用這樣的架構，那麼須要牢記這一點。如今，沒法告訴NCP忽略這些命名空間建立命令，所以它不會在NSX-T內部生成對象。