从零开始搭建Kubernetes - 基地

机缘巧合，部门在用的一批固定资产管理权限转移到了我的名下。交接用的Excel表格中显示有数十台机架式服务器，具体配置不详。正好最近看了一本关于Kubernetes的书籍，突然萌生了一个念头——这么多机器，不正好可以用来搭建一个Kubernetes集群吗？

不过，困难也有：

• 机器配置不详，除了固定资产编号，一无所知。
• 机器用途不详，哪些是用于开发的，哪些是用于测试的，哪些是用于业务保障的，都是未知。

不仅如此，在现场清点时还发现：

• 部分机器故障指示灯已经亮起。
• 部分机器处于关机状态，状态不详。
• 额外还有若干无固定资产编号的机器归属本部门，状态不详。

一句话概括：部门有一批正在使用中的服务器，细节不详。

所以，工作第一步是摸底——搞清楚机器现状。

建立服务器现状记录表

服务器的现状大致包含以下信息：

• 服务器的主要配置：CPU、内存、磁盘、基础操作系统、业务IP地址、管理IP地址。
• 服务器的物理状态：是否存在硬件故障？
• 服务器的业务属性：是否正在运行关键业务？
• 服务器的使用者与管理员。
• 服务器在机房机柜里的具体位置。

这些内容可以很方便的记载在Excel表格里，不再赘述。

另外，服务器的机房机柜是一种标准化的人造物品。所以，完全可以使用Excel表格来直观记录物理机在机房机柜里的位置。如下图：

通常机柜以U为高度单位。上图展示了一台高度为42U的机柜。一台机架式服务器也是以U为高度衡量单位，常见的有2U、4U。据此你可以大致推算一个机柜能够存放的机器数量。不过要留意机柜中同时还会有交换机、供电系统、KVM等设备存在。他们也会占据一定空间。所以最好实地测量，并标记出这些设备占据的真实位置，方便后期调整机器位置时使用。

表格模板调整完毕后，便可以根据实际情况填充具体内容。不过在此之前，需要保证每一台物理机器处于活动状态。

确保每一台物理机都处于活跃状态

现代服务器基本上都可以通过网络实现远程管理。但是这是以物理机在线为前提条件的。

具体措施包括：

• 肉身去机房，将每一台物理机的编号与位置记录在表格中。
• 给没有编号的机器赋予内部编号，记录在表格中。
• 将处于关机状态的服务器启动。
• 记录存在硬件故障的机器。

这一步骤完成，便可以离开机房了。机房里某些机器的暴力风扇噪声尖锐刺耳、堪比飞机场。注意使用保护措施，避免久留。

更新物理机信息

在部门同事的帮助下，我拿到一份记载了部分服务器信息的Excel表格。这份表格里记录了固定资产编号与物理机的IP地址、位置，以及其上虚拟机IP地址和用途。不过表格中的信息存在以下问题：

• 数量不完整，没有记录全部机器信息。
• 内容不完整，没有硬件信息、没有虚拟机的使用者信息。
• 数据以“报表”的形式记录，依靠手工维护，很难使用Excel的公式实现自动化统计。

所以，这份旧表可以用作参考，后期将使用新表格将其替换。

更新信息没有什么太好的办法，第一次都是手动操作。具体：

• 对于Linux系统，通过SSH远程访问，使用 lshw 命令列出硬件信息。
• 对于Windows系统，通过远程桌面登录访问，记录硬件信息。
• 对于虚拟化系统如ESXi，低版本需要使用Vsphere Client来连接远程服务器，获取硬件信息。高版本可以直接访问web管理界面获取信息。

在这个过程中，很有可能遇到某些机器处于开机状态，但是无法远程访问的情况。这种状况下只能再次肉身前往机房，连接显示器与键盘，排查故障原因。

如此重复数次，直到全部无故障机器处于在线运行状态，且被完整的记录在表格中。

至此，摸底工作基本完成。此刻你应当：

• 清楚的知道部门内当前有多少台物理机器在运行。
• 每一台机器的配置可以方便地查询到。
• 每一台机器都可以通过远程访问管理。
• 每一台机器的使用者/管理员是明确的。
• 每一台机器的业务属性是清晰的，尤其是关键业务。

我的本职工作是算法开发，所以这些事情只能抽时间去做。完成全部内容我大概花了2~3周的时间。

制作调整计划

在补充信息与排查过程中，所有的问题都会自然暴露出来了。例如：