Kubernetes The Hard Way：Jumpbox 搭建详解——为手工引导集群准备管理主机与全套组件二进制

本篇围绕 kubernetes-the-hard-way 教程中的 Jumpbox（跳板管理机）搭建展开：它会讲清为何要单独设置一台管理主机、如何在其上安装命令行工具、克隆教程仓库、按架构清单批量下载 Kubernetes 1.32 全家桶二进制（kubectl、kube-apiserver、etcd、containerd、CNI 插件等），以及如何按 client/controller/worker 的角色目录组织这些二进制，为后续引导 etcd、控制平面与工作节点打好物料基础。读完本篇，你将掌握一套可直接复制执行的 Jumpbox 初始化流程，并理解每个下载与解压步骤背后的设计意图。

Jumpbox 是什么，为什么需要它

在 kubernetes-the-hard-way 的整套实验（labs）中，需要 4 台基于 ARM64 或 AMD64 架构、运行 Debian 12 (bookworm) 的虚拟机或物理机：一台 jumpbox（管理主机，1 核 / 512MB / 10GB）、一台 server（承载全部控制平面组件，1 核 / 2GB / 20GB）、两台 node-0 与 node-1（工作节点，各 1 核 / 2GB / 20GB）。这些规格要求记录在 docs/01-prerequisites.md 中。

jumpbox 的定位是管理主机（administration machine）：它是你从零搭建 Kubernetes 集群时的“大本营（home base）”，教程中后续所有操作命令都将从这台机器发起。选择一台专用机器是为了保证实验环境的一致性，但文档也明确说明：这些命令几乎可以在任何机器上运行，包括运行 macOS 或 Linux 的个人工作站。

之所以把二进制下载集中在 jumpbox 上完成，是一个关键的带宽与一致性设计：所有组件二进制只会下载一次，存放在 jumpbox 的 downloads 目录中，之后复制到 server 和 node-0/node-1 时使用的是局域网传输，避免了为每台机器重复从公网下载。整个教程需要下载的二进制总量超过 500MB，集中下载一次能显著节省时间。

登录 Jumpbox：以 root 身份操作

首先通过 SSH 登录到 jumpbox：

ssh root@jumpbox

教程中所有命令都以 root 用户执行。这是出于便利性的考虑——root 身份可以避免在每一步操作中反复提权，减少命令数量。需要注意这一做法仅适用于实验环境，生产环境中以专用低权限用户操作是更规范的做法。

安装命令行工具

登录 jumpbox 后，先更新 APT 软件源索引，然后安装后续实验将用到的命令行工具：

{
  apt-get update
  apt-get -y install wget curl vim openssl git
}

各工具在后续 labs 中的分工：

工具	在教程中的用途
wget	下载 Kubernetes 及各组件二进制
curl	校验二进制完整性（SHA256 校验）等
vim	编辑生成的配置文件
openssl	生成 CA、证书与密钥（见 docs/04-certificate-authority.md）
git	克隆本教程仓库

克隆教程仓库

接下来下载教程仓库本身。仓库中包含后续实验用到的额外配置文件（如 systemd 服务单元、containerd 配置、kubelet 配置等），是搭建过程不可或缺的“物料包”：

git clone --depth 1 \
  https://github.com/kelseyhightower/kubernetes-the-hard-way.git

--depth 1 表示只浅克隆最近一次提交，跳过完整历史，加快下载速度。

进入仓库目录：

cd kubernetes-the-hard-way

此后这里就是整个教程的工作目录。如果在执行命令时不确定当前所处位置，随时可以用 pwd 确认：

pwd

/root/kubernetes-the-hard-way

仓库中与 Jumpbox 下载流程直接相关的文件有两个：downloads-amd64.txt 与 downloads-arm64.txt，它们分别列出 AMD64 与 ARM64 架构下需要下载的全部二进制 URL。

查看架构对应的下载清单

本教程的二进制清单按 CPU 架构分为两个文件。用 dpkg --print-architecture 可以自动识别当前机器的架构（Debian 系系统返回 amd64 或 arm64），据此选择对应清单：

cat downloads-$(dpkg --print-architecture).txt

以 downloads-amd64.txt 为例，其中列出的组件及版本为：

组件	版本	来源	角色
kubectl	v1.32.3	dl.k8s.io	客户端命令行工具
kube-apiserver	v1.32.3	dl.k8s.io	控制平面 API 服务器
kube-controller-manager	v1.32.3	dl.k8s.io	控制平面控制器管理器
kube-scheduler	v1.32.3	dl.k8s.io	控制平面调度器
kube-proxy	v1.32.3	dl.k8s.io	节点网络代理
kubelet	v1.32.3	dl.k8s.io	节点代理
crictl	v1.32.0	cri-tools releases	CRI 调试工具
runc	v1.3.0-rc.1	opencontainers releases	OCI 容器运行时
CNI plugins	v1.6.2	containernetworking releases	容器网络插件（含 bridge 等）
containerd	v2.1.0-beta.0	containerd releases	容器运行时
etcd	v3.6.0-rc.3	etcd releases	分布式键值存储（集群状态存储）

这组版本与 README 中声明的组件版本（Kubernetes v1.32.x、containerd v2.1.x、CNI v1.6.x、etcd v3.6.x）一一对应。ARM64 的清单 downloads-arm64.txt 结构完全相同，只是 URL 中的架构标识从 amd64 变为 arm64，二进制名中的架构字段相应变化（如 runc.arm64）。

批量下载二进制到 downloads 目录

使用 wget 按清单批量下载所有二进制，并存放于 downloads 目录：

wget -q --show-progress \
  --https-only \
  --timestamping \
  -P downloads \
  -i downloads-$(dpkg --print-architecture).txt

各选项的作用：

• -i <file>：从文件中逐行读取 URL 列表，实现清单式批量下载；
• -P downloads：指定下载目标目录为 downloads，这也是教程后续所有 labs 约定的二进制暂存位置；
• --https-only：强制仅使用 HTTPS 下载，保证来源可信与传输加密；
• --timestamping：启用时间戳比较——若本地文件比远程更新则跳过下载，便于中断后断点重跑，避免重复下载；
• -q --show-progress：抑制冗余输出但保留进度条。

由于总量超过 500MB，下载耗时取决于网络带宽。完成后用 ls 检查：

ls -oh downloads

-oh 参数以人类可读的容量单位显示文件大小，便于核对各二进制是否正常落地。

解压并按角色目录组织二进制

下载得到的是散落在 downloads 根目录下的可执行文件与压缩包。下一步将它们解压并归入四个角色子目录：

{
  ARCH=$(dpkg --print-architecture)
  mkdir -p downloads/{client,cni-plugins,controller,worker}
  tar -xvf downloads/crictl-v1.32.0-linux-${ARCH}.tar.gz \
    -C downloads/worker/
  tar -xvf downloads/containerd-2.1.0-beta.0-linux-${ARCH}.tar.gz \
    --strip-components 1 \
    -C downloads/worker/
  tar -xvf downloads/cni-plugins-linux-${ARCH}-v1.6.2.tgz \
    -C downloads/cni-plugins/
  tar -xvf downloads/etcd-v3.6.0-rc.3-linux-${ARCH}.tar.gz \
    -C downloads/ \
    --strip-components 1 \
    etcd-v3.6.0-rc.3-linux-${ARCH}/etcdctl \
    etcd-v3.6.0-rc.3-linux-${ARCH}/etcd
  mv downloads/{etcdctl,kubectl} downloads/client/
  mv downloads/{etcd,kube-apiserver,kube-controller-manager,kube-scheduler} \
    downloads/controller/
  mv downloads/{kubelet,kube-proxy} downloads/worker/
  mv downloads/runc.${ARCH} downloads/worker/runc
}

这段脚本的要点：

• ARCH=$(dpkg --print-architecture)：把当前架构（amd64/arm64）缓存进变量，用于拼接各压缩包文件名；
• tar --strip-components 1：解压时丢弃最外层目录（如 containerd-2.1.0-beta.0-linux-amd64/），让二进制直接落到目标目录，避免嵌套；
• 解压 etcd 时通过位置参数只挑出 etcd 与 etcdctl 两个文件，跳过包内其他无关内容；
• crictl 与 containerd 直接解入 worker/，因为它们是工作节点运行时栈的一部分。

最终目录布局按“谁使用”划分：

目录	内容	后续被哪个 lab 复制使用
downloads/client/	etcdctl、kubectl	控制平面与工作节点 lab 都会取用 kubectl 做校验
downloads/controller/	etcd、kube-apiserver、kube-controller-manager、kube-scheduler	引导 etcd 与控制平面（docs/07-bootstrapping-etcd.md、docs/08-bootstrapping-kubernetes-controllers.md）
downloads/worker/	kubelet、kube-proxy、containerd、crictl、runc	引导工作节点（docs/09-bootstrapping-kubernetes-workers.md）
downloads/cni-plugins/	CNI 插件二进制	工作节点 lab 中复制到 /opt/cni/bin

这个划分与教程的节点角色完全对应：控制平面组件集中在 server，工作节点组件分布在 node-0/node-1。从后续文档的引用方式可以印证这一布局的实际消费路径：docs/07-bootstrapping-etcd.md 使用 downloads/controller/etcd 与 downloads/client/etcdctl；docs/08-bootstrapping-kubernetes-controllers.md 使用 downloads/controller/ 下的三个 kube 组件；docs/09-bootstrapping-kubernetes-workers.md 则整体复制 downloads/worker/* 与 downloads/cni-plugins/*。

解压完成后清理压缩包并赋予执行权限：

rm -rf downloads/*gz

{
  chmod +x downloads/{client,cni-plugins,controller,worker}/*
}

chmod +x 对四个子目录下的所有文件一次性加执行位，保证后续 scp 到各节点后能直接运行。

在 Jumpbox 上安装 kubectl

kubectl 是 Kubernetes 官方命令行客户端。虽然它最终会在 server 与 node-0/node-1 上安装（各节点都需要本地副本用于调试），但先在 jumpbox 上装好一份，是为了让你之后能与已完成供给的集群控制平面交互：

{
  cp downloads/client/kubectl /usr/local/bin/
}

安装完成后验证版本：

kubectl version --client

Client Version: v1.32.3
Kustomize Version: v5.5.0

--client 参数表示只输出客户端信息、不连接集群，因此即使此时还没有任何集群也可以运行——这正是验证安装是否成功的标准方式。输出版本 v1.32.3 与 downloads-amd64.txt 中 dl.k8s.io/v1.32.3/ 的下载路径一致，说明客户端与后续部署的服务端组件版本对齐。

小结：Jumpbox 在整体流程中的位置

完成本篇后，jumpbox 上已具备：

1. 全部命令行工具（wget、curl、vim、openssl、git）；
2. 教程仓库工作目录 /root/kubernetes-the-hard-way，内含 units/、configs/ 等后续 labs 要分发的 systemd 单元与配置文件（如 units/etcd.service、units/kube-apiserver.service）；
3. 按 client/controller/worker/cni-plugins 组织、可执行的完整二进制物料库；
4. 可工作的 kubectl 客户端。

这些正是后续各 labs 的输入：下一站 Provisioning Compute Resources 将在 server 与 node-0/node-1 上配置静态网络、systemd 重载行为与 iptables 内核转发，为分发这些二进制做好准备。