本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前述文章透过不同的安装方式让 Rancher 管理三套不同的 Kubernetes 丛集，其中有两套丛集是基於 RKE 的版本，而另外一个则是 Azure AKS。

这三个丛集除了安装的方式不同外，实际上因为底层的限制与安装方式的不同，网页操作上会有一些功能有些许不同，而本章节就会开始来探讨要如何使用 Rancher 的介面来管理这些 Kubernetes 丛集。

丛集存取

对於大部分的 Kubernetes 工程师来说， kubectl 是个必须要会的使用工具，而 dashboard 更多时候是作为一个辅助的工具，提供更友善的视觉化方式来有效的提供资讯。
Rancher 本身提供非常友善的 Dashboard，可以让非工程人员也可以快速地浏览与理解当前 Kubernetes 丛集的状态，举例来说随便点进一个之前创立的 Kubernetes 丛集，会看到如下的画面。

画面中有几个点可以注意

1. Rancher 内部有两种浏览介面，分别是 Cluster Manager 以及 Cluster Explorer，预设情况下都是使用 Cluster Manager 来浏览
2. Rancher v2.5 之後将慢慢的转往 Cluster Explorer 去使用，所以可以观察到画面上都有提示，告知使用者可以尝试使用看看 Cluster Explorer 来管理与浏览 Kubernetes 丛集
3. 画面中间大大的显示了三个关於 Kubernetes 资源的资讯，CPU, Memory 以及 Pod 的数量。Kubernetes 预设情况下每个节点最多只能部署110个 Pod，所以画面中显示的是 18/330，代表说目前已经有 18 个Pod 部署了。而 CPU/Memory 代表的则是有多少系统资源已经被预先保留，这部分是透过 Pod 里面的 Resource.Request 来处理的
4. 最下面还有四个健康状态，代表整个丛集中的 Etcd, Control Plane(Controller,Scheduler) 以及节点之间的健康状态
5. 最下面 Events 展开则是可以看到 Kubernetes 内的相关 Event

上述的 Portal 简单地呈现了当前 Kubernetes 丛集是否健康，特别是当丛集有任何问题时，下方的四个状态都会变成红色醒目的提醒使用者丛集有问题。

有了基本介面後，接下来把注意力移动到右上方两个选项，分别是 Launch kubectl 以及 Kubeconfig File。
点选 Kubeconfig File，则会看到类似下列的画面，该画面中呈现的就是完整的 Kubeconfig file 内容。

这意味你可以把该档案抓到你的电脑，直接於本地端使用 Kubectl 指令去存取目标丛集，示范中使用的是给 DEV 人员操作的丛集，所以该 Kubectl 本身对应的使用者其实也就是我当前用来登入 Rancher 系统的使用者。
如果熟悉 Kubeconfig 格式的读者会观察到, Rancher 本身会针对 Clusters 这个栏位填入多个组合，这些组合分两大类，分别是

1. 丛集中的 API Server 位置
2. Rancher Server 本身

假如今天你有办法直接存取到目标节点，譬如节点本身有 Public IP 且也有开启 6443 Port，那就可以使用这个方式直接存取该 Kubernetes 丛集。
但是如果该节点今天是一个封闭的环境，没有任何 Public IP 可以直接存取，那可以采取第二种方式，把任何 API 请求都打向 Rancher 服务，如图中的 "https://rancher.hwchiu.com/k8s/clusters/c-z8j6q" 这个位置，然後 Rancher 就会帮忙把请求给转发到目标丛集内，可以想像成是一个 Proxy By Pass 的概念。

补充一下: 因为目标 Kubernetes 丛集内都会安装 Rancher 相关的服务，这些服务都会主动的跟 Rancher 进行连线，所以 Rancher 才有办法把这些 API 请求给转发到这些不能被外界主动存取的 Kubernetes 丛集。

以下是个范例，将上述档案存成一个名为 ithome 的档案，接者执行 kubectl 的时候可以透过 --kubeconfig 的参数来指定当前 kubectl 要使用哪个档案

上述指令就呈现了当前 DEV 丛集中的相关 Pod 资讯，其中可以看到

1. Flannel CNI 符合之前 RKE Template 的选择
2. RKE 丛集有满多相关的服务
3. cattle-system 有所谓的 cattle-node-agent，这些角色就是会负责跟 Rancher 沟通。

基本上只有拥有了 KUBECONFIG 的档案，管理者就有办法透过 kubectl,helm 等指令直接管理该丛集。
如果系统上刚好没有安装这些指令，但是又想要使用 kubectl 来操作怎麽办？
Rancher 也想到了这一块，所以丛集画面右上方的 Launch Kubectl 按钮给他点下去，
该功能会开启一个 web-based 的终端机，里面提供了 kubectl 的指令，同时 kubeconfig 也都设定完毕了。
所以可以直接於该环境中使用 kubectl 去操作丛集，范例如下

基本上掌握这两个功能的用法，就等於掌握了直接操作当前 Kubernetes 丛集的能力，习惯使用 kubectl 的使用者也可以开始透过 kubectl 来管理与部署该 Rancher 上的各种应用，当然 Rancher 本身也有自己的架构能够让使用者去部署应用程序，好坏没有绝对，都要进行评估与比较。

Kubectl 与 Kubecfongi File 旁边有一个按钮，该按钮点下去後可以看到一些关於 Kubernetes 丛集的选项，而不同的搭建的丛集显示的功能都不同，譬如

如果节点是透过 AKS 搭建的，可以看到选项非常少，只有编辑与删除是常见会使用的功能，编辑页面中可以针对丛集名称，丛集的使用权限，甚至针对 K8S 丛集的选项进行调整。不过由於该丛集是由 AKS 维护的，所以修改的内容也都是跟 AKS 有关。

第二个看到的是透过 Docker 指令於现存节点上安装的 RKE 丛集，这种状况下可以选择的操作非常多，譬如

1. Rotate Certificates，该功能主要是针对 Kubernetes 内各元件沟通用的凭证，譬如 API Server, Controller..等
2. Snapshot 主要会针对 etcd 进行备份与还原，该备份并没有办法针对使用者部署的应用程序去处理备份跟还原，之後可以细谈一下这块
3. Registration Cmd，由於该丛集是透过让节点运行 Docker 指令将其加入到 RKE 丛集中，因此如果今天有新的节点要使用时，就可以直接点选该指令取得相关的 docker 指令，介面中也可以重新选择身份与相关的标签/Taint等。
4. Run CIS Scan，这个功能会慢慢被淘汰，v2.5 後 Cluster Explorer 内关於 App 的管理方式有更好的处理方式，建议使用那边的 CIS 处理。

最後一个则是透过 API 请求 Azure 创造 VM 的 RKE 丛集，基本上差异就只是没有 Docker 指令可以处理。

从上述三个丛集的观察到可以发现， Rancher 很多功能都跟 RKE 丛集有关，所以如果今天是让 Rancher 管理并非是由 Rancher 创造的丛集，功能上都会有所限制，并不能完全发挥 Rancher 的功能。

看完丛集相关的状态後，切换到节点页面，节点页面也会因为不同安装方式会有不同的呈现方式

下图是基於 AKS 所创造的丛集，该丛集显示了三个节点，这些节点因为 AKS 的关系被打上了非常多的标签。

如果该丛集是透过 API 要求 Azure 动态新增 VM 所创造的丛集，则该页面是完全不同的类型

上述画面中有几个点可以注意

1. 每个 Node Pool 都是独立显示，可以看到该 Node Pool 下目前有多少节点，每个节点的 IP 等资讯
2. 每个 Node Pool 右方都有 +- 两个按钮，可以让你动态的调整节点数量
3. 由於这些节点都是动态创立的，因此如果今天有需求想要透过 SSH 去存取这些节点的话，实际上可以到每个节点旁边的选项去下载该节点的 SSH Keys，这个功能是只有这种创造方式的丛集才拥有的。其他创造方式的丛集节点没有办法让你下载相关的 SSH Key。

上述画面除了 Cluster, Nodes 外还有其他选项，Member 页面可以重新设定到底该丛集的拥有者与会员有谁，譬如最初 DEV 丛集只有 DEV 群组的使用者可以操作，目前尝试将 QA 群组的使用者加入进去，并且设定权限为 Cluster Member，设定完後的画面如下。

这种情况下，如果使用 QA 使用者登入，就可以看到这个 DEV 丛集，接者使用该 QA 使用者尝试去存取该 DEV 丛集并且获取该 Kubeconfig 就可以顺利的使用了。

如果熟悉 Kubernetes RBAC 的读者，可以尝试挖掘一下到底 Rancher 是如何把设定的这些权限给对应到 Kubernetes 内的权限。下图是一个范例。

下图是 QA 使用者存取 DEV 丛集用的 Kubeconfig，可以看到 User 部分使用的 Token 进行验证，该 Token 中有一个资讯代表的是该 User 的 ID，u-dc5fezjbyi

拥有该资讯後，可以到该 Kubernetes 丛集内去找寻 cattle-system 底下 ClusterUserAttribute 这个物件，看看是否有符合这个名称的物件，找到後可以看到该物件描述了这使用者本身有一个 Group 的属性。
该 Group 很明显跟 Azure 有关，其值为 azuread_group://ec55ce9e-dbd4-427c-905c-d8063b19f150.
这个 Group 就会被用到 ClusterRoleBinding 中的 Subject

因此透过 kubectl 搭配 jq 的一些语法去找，看看有没有哪些 ClusterRoleBinding 里面是对应到这个 Group 群组，可以发现系统中有四个物件符合这个情况，而这四个物件对应到的 Role 分别是 read-only-promoted, cluster-member, p--namespaces-readonly，後面那个包含 "p-" 字串的物件会跟之後探讨的 Project 概念有关。

接者有兴趣的可以再继续看这些不同的 Roles 实际上被赋予什麽样的权限与操作。

除了 Member 可以操作外， Cluster 还有一个 Tools 的清单可以玩

里面有很多第三方整合工具可以安装，但是如果是 v2.5 的使用者，非常建议直接忽略这个页面，因为这边都是旧版安装与设
定行为，v2.5 後这些整合工具除了 Catalog 外基本上都已经搬移到 Cluster Explorer 页面去安装与操作。
因此接下来就尝试进入到 Cluster Explorer 来看看这个 Rancher 想要推广的新操作介面。

Cluster Explore 的介面跟 Cluster Manager 是截然不同的，这边列出几个重点

1. 右上方可以选择当前是观看哪个丛集，可以快速切换，同时提供一个按钮返回 Cluster Manager.
2. 中间简单呈现当前 Kubernetes 丛集的资讯，版本，提供者与节点资讯
3. 跟之前一样呈现系统的资源使用量，不过 CPU/Memory 本身同时提供当前使用量已经当前被预约使用量，这两个数字可以更好的去帮助管理员去设计当前相关资源的 request/limit 要多少
4. 左上方是重要的功能选单，不少功能都可以点选该处来处理
5. 左下方呈现 Kubernetes 中的各项资源，每个资源都可以点进去观看，譬如 ClusterRoleBinding 就会更友善的呈现每个物件对应到的到底是 User ， Group 还是 Service Account。

点选左上方 Cluster Explorer 後切换到 Apps & Marketplace，可以看到类似下方的画面

该画面中呈现了可以让使用者轻松安装的各类应用程序，这些应用程序分成两大类，由 Rancher 自行维护整合的或是由合作夥伴提供的。
如果安装的是由 Rancher 整合的 Application，那安装完毕左上方都会出现一个针对该 App 专属的介面，譬如我们可以尝试安装 CIS Benchmark。

安装过程中，画面下方会弹出一个类似终端机的视窗告知使用者安装过程，待一切安装完毕後可以透过画面中间的 "X" 来关闭这个视窗。

接者重新点选左上方的清单就会看到这时候有 CIS Benchmark 这个应用程序可以使用，该应用程序可以用来帮助管理去扫描 Kubernetes 丛集内是否有一些安全性的疑虑，该专案背後是依靠 kube-bench 来完成的，基本上 Rancher 有提供不同的 Profile 可以使用，所以对於安全性有需求的管理员可以安装这个应用程序并且定期扫描。

一个扫描的示范如上，该图片中显示了使用的是 rke-profile-permissions-1.6 这个 profile，然後跑出来的结果有 62 个通过， 24 个警告， 36 测试不需要跑。
如果拿 RKE 的 profile 去跑 AKS 的丛集就会得到失败，因为 RKE 的 profile 是针对 RKE 的环境去设计的，因此可能会有一些功能跟 AKS 的设计不同，会失败也是可以预料的。

Rancher 本身提供的 Application 非常多，下篇文章就来仔细看看其中最好用的 Monitoring 套件到底能够提供什麽功能，使用者安装可以如何使用这个套件来完成 Promethues + Grafana 的基本功能。