Day 8 - Rancher 丛集管理指南 - 架设 K8s(上)

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

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

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

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

前言

前述文章探讨的都是基於一个系统管理员的角度下,可以如何使用 Rancher 这个管理平台来符合整个团队的需求,譬如 RKE Template 以及最重要的使用者登入与权限控管。
当 Rancher 系统有了妥善的规划与设定後,下一步就是踏入到 Rancher 最重要的功能,也就是 Kubernetes 管理。

前篇文章探讨 RKE Template 的时候有介绍过 Rancher 有四种新增 Kubernetes 丛集的方式,第一种是将已经存在的 EKS/GKE 等丛集直接汇入到 Rancher 中,而剩下三种是根据不同架构来产生一个全新的 RKE 丛集并且汇入到 Rancher 中。

这三种架构以目前的环境架构如下图所示

Rancher 有三种方式可以架设 RKE,从右到左分别是

  1. 透过 API 请求 Azure 帮忙创建 AKS,并且把 Rancher 相关的 agent 安装到该 AKS 中
  2. 透过 API 请求 Azure 创造 VM 丛集,接者於这些 VM 上安装 RKE 丛集
  3. 直接於已经存在的节点上搭建一套 RKE 丛集

接下来就示范这三种用法有何不同,以及当 RKE 丛集创建出来後该如何使用

环境实验

三种环境中,我认为相对复杂的是第二种,如何请求 Azure 创建 VM 并且安装 RKE 丛集。
所以先从这个较为复杂的情况开始探讨,掌握这个概念後後续两个(1)(3)都较为简单,使用上也就不会有太多问题。

第二种的安装模式将其仔细摊开来看,其实有几个重点需要完成

  1. 选择一个想要使用的 Service Provider
  2. 准备好该 Service Provider 沟通用的设定,譬如帐号密码, Token 等
  3. 规划需要准备多少台 VM,每个 VM 要用何种规模(CPU/Memory),该机器要扮演 Kubernetes 什麽角色
  4. 规划 RKE 的设定

Service Provider

第一点是选择一个想要使用的 Service Provider,由於之前的环境都是基於 Azure 去使用,因此我接下来的范例都会基於 Azure 去架设。

下图是一个 Rancher 预设支援的 Service Provider,包含了 AWS, Azure, DigitalOcean, Linode 以及 vSphere.

实际上 Rancher 内部有一个名为 Node Driver 的资源专门用来管理目前支援哪些 Service Provider,该资源是属於系统层级,也就是整个 Rancher 环境共享的。

Driver (Tools->Driver) 页面中显示了两种不同的 Driver,分别是 Cluster Driver 以及 Node Drivers.

预设的 Node Driver 状态如下,可以看到 Driver 分成两种状态,分别是 Active 以及 Inactive,而上图中显示的 AWS/Azure/Digital/Linode/vSphere 都属於 Active。

尝试将上述所有 Inactive 的 Drive 都 active 後,这时候重新回去 Cluster 创建页面看,就可以发现目前支援的 Service Provider 变得超级多。

所以如果团队使用的 Service Provider 没有被 Rancher 预设支援的话,别忘记到 Driver 处去看看有没有,也许只是属於 Inactive 的状态而已。

Access Credentials

选择 Service Provider(Azure) 後的下一个步骤就是要想办法让 Rancher 跟 Azure 有办法沟通,基本上 Service Provider 都会提供相关的资讯供使用者使用。

这边试想一下,这种帐号密码资讯的东西如果每次创建时都要一直重复输入其实也是相对烦人的,所以如果有一个类似 RKE Template 概念的物件,就能够让使用者更为方便的去使用。
譬如使用者只需要事先设定一次,接下来每次要使用到的时候都去参考事先设定好的帐号密码资讯即可。

Rancher 实际上也有提供这类型的机制,称为 Cloud Credentials,其设定页面位於个人使用者底下,

接者点选创建一个 Cloud Credential 并且将 Cloud Credential Type 设定为 Azure 後就会出现 Azure 应该要输入的相关资讯,对於熟悉 Azure 的读者来说这三个设定应该不会太陌生,基本上 Rancher 官方都有针对这些类别提供简单的教学文件。

一切准备就绪後就可以创建一个基於 Azure 的 Cloud Credential 了。未来其他操作如果需要 Azure 相关的帐号密码时,就不需要一直重复输入,而是可以直接使用这组事先创建好的连接资讯。

VMs

当 Rancher 准备好如何跟 Service Provider(Azure) 沟通後,下一个要做的就是使用者要去思考,希望这个创建的 RKE 丛集有多少个节点以及相关设定。这些节点都会是由 Rancher 要求 Azure 动态创立的,每个节点都需要下列资讯

  1. 节点的 VM 规模,多少 CPU,多少 Memory
  2. 该 VM 要用什麽样的 Image,什麽样的版本,登入角色要用什麽名称,有没有 Cloud-Init 要运行
  3. 每个 Service Provider 专属设定
  4. 该节点於 Kubernetes 内扮演的角色,角色又可以分成三种
    a. etcd: 扮演 etcd 的角色,要注意的是 etcd 的数量必须是奇数
    b. control plane: Kubernetes Control Plane 相关的元件,包含 API Server, Controller, Scheduler 等
    c. worker: 单纯的角色,可以接受 Control Plane 的命令将 Pod 部署到该节点上。

从上述的资讯可以观察到,要创建一个 RKE 资讯光节点这边要输入的资讯就不少,所以如果每次创建 RKE 丛集都要一直重复输入上列这些资讯,其实带来的麻烦不下 Credential 与 K8s 本身。

这个问题 Rancher 也有想到,其提供了一个名为 Node Template 的物件让使用者可以去设定 VM 的资讯,同时为了让整个操作更加弹性与灵活,上述四个步骤其实分成两大类

  1. VM 本身的设定 (1~3)
  2. 该 VM 怎麽被 RKE 使用 (4)

Node Template 要解决的是第一大类的问题,让 VM 本身的设定可以重复利用,不需要每次输入。
使用者要创立ㄧ个新的 RKE 丛集时,可以直接使用创造好的 NodeTemplate 设定 VM 资讯,接者根据当前需求决定该节点应该要以何种身份於 RKE 丛集中使用。

Node Template 与 Cloud Credential 一样,都可以於使用者底下的页面去设定。
进入到页面後可以看到目前支援的 Service Provider,因为先前有将所有 Node Driver 都打开,所以这边的选择就非常的多。

当选择为 Azure 後,底下的 Account Access 就会出现之前创立的 Cloud Credential。
如果想要创建新的也可以於这个页面直接创立该 Cloud Credential。


接者下列就是满满的 VM 设定,这边的设定内容都跟该 Service Provider 有关 可以看到

  1. image 预设是 canonical:UbuntuServer:18.04-LTS:latest,
  2. Size 是 Standard_D2_v2
  3. SSH 的使用者名称是谁
  4. 硬碟空间预设是 30GB

上述还有非常多的设定,除非对这些选项都非常熟悉,不然大部分情况下都可以采取预设选项
一切就绪後给予该 Node Template 一个名称并且储存。

实务上通常会针对不同大小的机器创建不同的 Node Template 并且给予名称时有一个区别,这样之後使用者要使用时就会比较清楚当前的 Node Template 会创造出什麽样的机器。

这边示范一下创建两个 Node Template 并且给予不同的名称

RKE

一切资讯都准备完毕後,接者就可以回到 Cluster 的页面去创造一个基於 Azure 的 RKE 丛集。


上图红匡处则是本文章重点处理的部分,也就是所谓的 Node Template。
对於 RKE 丛集来说,会先透过 Node Template 来定义一个 Node Pool,每个 Node Pool 需要定义下列资讯

  1. 该 Node Pool 名称
  2. Pool 内有多少节点
  3. 该 Node Pool 要基於哪个 Node Template 来创造
  4. 本身要扮演什麽身份

同时 UI 也会提醒你每个身份应该要有多少个节点,譬如 etcd 要维持奇数, Control Plane/Worker 至少都要有一个节点。

决定好丛集身份後,下一件事情就是权限,到底谁有权限去使用这个 RKE 丛集,预设情况下有两种身份,分别是

  1. Cluster Owner: 该使用者拥有对该丛集的所有操控权,包含里面的各种资源
  2. Cluster Member: 可以读取观看各种相关资源,写的部分是针对底下的专案去操作,没有办法对 Cluster 本身进行太多操作,这部分之後会探讨丛集内的专案概念时会更加理解。

一切准备就绪就给他点选创立,接者就是慢慢等他处理,整个过程会相对漫长,因为需要从 VM 开始创立,接者才去创建 RKE 丛集。
当画面显示如下时,就代表者相关丛集已经创建完毕了。

这边可以看到,跟之前用来存放 Rancher 的 RKE 不同,这个新创的 RKE 丛集其 Provider 标示为 Azure。

同时我的 Azure VM 中也真的产生出三个新的VM,这些 VM 的名称与规格都与之前设定的完全一样。

下一章节会继续介绍另外两种不同的安装方式,并且会基於这三种不同方式安装三个不同类型的丛集,之後探讨到 Rancher Fleet 这个 GitOps 的概念时,就会使用 GitOps 来部署应用程序到这三个不同的丛集。


<<:  Day 0x7 UVa11417 GCD

>>:  全端入门Day08_何谓全端之後端末篇

[面试]准备好要询问公司的问题,面试就是资讯战!

打着「吃亏就是占便宜」的口号,许多人别说去争取不属於自己的东西,连属於自己的东西都没有开口的勇气。...

iOS APP 开发 OC 第二十二天,Portocol

tags: OC 30 day 什麽是Protocol? 作用:专门用来声明一大堆方法。(不能声明属...

Rust-并行&并发(二)

channel 通常channel都是搭配并行使用,没有使用并行就没有使用channel的意义 「别...

Day17 - 铁人付外挂前置作业(二)- 开发环境

在自己的电脑中建立一个 WordPress 需要的材料有 PHP、Apache or Nginx 以...

EP24 - 持续部署使用 Octopus Deploy 四部曲,整合 Jenkins 自动部署到 EKS

今天终於将实作做完了, 前几天我们都在调整系统底层的设定, 为的就是在 UI 上面可以直接连接, 今...