近万字案例文：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内部生成对象。
- 1. 近万字案例文：Rancher + VMware PKS实现全球数百站点的边缘K8S集群管理
- 2. Rancher + VMware PKS实现全球数百站点的边缘K8S集群管理
- 3. Rancher管理k8s集群
- 4. centos7 部署rancher管理k8s集群
- 5. kubernetest:部署rancher 管理 k8s集群
- 6. 多k8s集群管理
- 7. rancher安装k8s集群
- 8. rancher下的k8s集群清理节点上的pod
- 9. K8S集群管理docker部署
- 10. k8s多集群配置管理平台
- 更多相关文章...
- • Swarm 集群管理 - Docker教程
- • 现实生活中的 XML - XML 教程
- • ☆基于Java Instrument的Agent实现
- • TiDB 在摩拜单车在线数据业务的应用和实践
-
每一个你不满意的现在，都有一个你没有努力的曾经。