2026/9/6 18:35:20
FEATURED · 精选文章 
Kubernetes The Hard Way从零引导单节点 etcd 集群kthw Lab 07 实战解析【免费下载链接】kubernetes-the-hard-wayBootstrap Kubernetes the hard way. No scripts.项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-the-hard-way在 Kubernetes The Hard Way 教程中Kubernetes 各控制面组件本身都是无状态的——它们的所有集群状态Node、Service、Deployment、Secret 等对象的真实数据都存储在一个名为 etcd 的分布式键值数据库中。本篇对应 Bootstrapping the etcd Cluster 实验带你以“无脚本、纯手工”的方式在server机器上安装并引导一个单节点 etcd 集群逐一剖析 units/etcd.service 中的每个启动参数的含义。读完本篇你将掌握etcd 二进制与 systemd 服务的部署流程、etcd 各监听端口的职责2379/2380、集群成员与数据目录的权限配置以及后续kube-apiserver如何以--etcd-servers参数接入这个数据后端。为什么 Kubernetes 需要 etcd从 README.md 的组件清单可以看到本教程使用的组件版本为kubernetes v1.32.x具体为 v1.32.3见 downloads-amd64.txtcontainerd v2.1.xcni v1.6.xetcd v3.6.x本仓库下载列表锁定为 v3.6.0-rc.3Kubernetes API Server 是唯一与 etcd 直接通信的控制面组件。kube-scheduler、kube-controller-manager等组件通过 API Server 间接读写集群状态。因此引导 etcd 是引导整个控制平面之前最关键的一步一旦 etcd 不可用集群将失去其持久化状态。本教程选择在server单机上引导一个单节点 etcd 集群足以支撑学习目的生产环境则通常需要 3 个或 5 个成员构成 Raft 集群。前置条件拷贝 etcd 二进制与 systemd 单元文件整个教程在四台 Debian 12 (bookworm) 机器上运行jumpbox、server、node-0、node-1硬件要求见 Prerequisites。etcd 的二进制文件已在 Set Up The Jumpbox 阶段从 downloads-amd64.txt或 downloads-arm64.txt统一下载并解压到jumpbox的downloads/目录下其中downloads/controller/etcdetcd 服务端二进制downloads/client/etcdctletcd 的命令行客户端工具本 Lab 的第一步是在jumpbox上把 etcd 二进制与 systemd 单元文件拷贝到server机器scp \ downloads/controller/etcd \ downloads/client/etcdctl \ units/etcd.service \ rootserver:~/之后登录server机器执行后续所有命令ssh rootserver注意本 Lab 的后续命令都必须在server机器上执行而不是jumpbox。安装 etcd 二进制在server机器上把etcd服务端与etcdctl命令行工具移动到 PATH 中的/usr/local/bin/{ mv etcd etcdctl /usr/local/bin/ }这一步完成后两个二进制都可以直接通过命令名调用。配置 etcd 服务目录与数据目录接下来创建 etcd 的配置目录与数据目录并把 TLS 证书放进配置目录{ mkdir -p /etc/etcd /var/lib/etcd chmod 700 /var/lib/etcd cp ca.crt kube-api-server.key kube-api-server.crt \ /etc/etcd/ }逐条拆解这个操作的用意/etc/etcd/存放 etcd 服务运行所需的证书等配置材料。这里复制了 Provisioning the CA and Generating TLS Certificates 实验在jumpbox生成并分发到server的三个文件ca.crtCA 根证书、kube-api-server.key与kube-api-server.crtkube-apiserver 的客户端证书/密钥对。这些证书在后续控制面组件中会被用作身份凭证。/var/lib/etcdetcd 的数据目录BBolt 数据库与 WAL 日志所在处对应 systemd 单元中的--data-dir/var/lib/etcd。chmod 700 /var/lib/etcd把数据目录权限收紧为仅 root 可读写执行。etcd 中存储着集群的全部状态其中可能包含 Secret 等敏感数据即便本教程后续用 生成数据加密配置 的 encryption-config 对其做静态加密收紧目录权限是基本的纵深防御措施。原文档还特别强调了一点etcd 集群中的每个成员必须拥有唯一的--name教程将该成员名设置为与当前计算实例的 hostname 一致本教程中为controller。这一点直接体现在下文的 systemd 单元里。深入解析 units/etcd.service 的每个启动参数把单元文件放入 systemd 目录mv etcd.service /etc/systemd/system/本仓库提供的 units/etcd.service 内容如下这也是理解 etcd 启动行为的核心[Unit] Descriptionetcd Documentationhttps://github.com/etcd-io/etcd [Service] Typenotify ExecStart/usr/local/bin/etcd \ --name controller \ --initial-advertise-peer-urls http://127.0.0.1:2380 \ --listen-peer-urls http://127.0.0.1:2380 \ --listen-client-urls http://127.0.0.1:2379 \ --advertise-client-urls http://127.0.0.1:2379 \ --initial-cluster-token etcd-cluster-0 \ --initial-cluster controllerhttp://127.0.0.1:2380 \ --initial-cluster-state new \ --data-dir/var/lib/etcd Restarton-failure RestartSec5 [Install] WantedBymulti-user.target参数逐一解析参数取值作用--namecontroller本成员在集群内的唯一标识教程要求其等于实例 hostname--initial-advertise-peer-urlshttp://127.0.0.1:2380告知集群中其他成员用哪个地址与本节点通信peer 流量--listen-peer-urlshttp://127.0.0.1:2380etcd 实际监听 peer/Raft 通信的端口2380--listen-client-urlshttp://127.0.0.1:2379etcd 实际监听客户端 API 请求的端口2379--advertise-client-urlshttp://127.0.0.1:2379对外通告的客户端接入地址供 kube-apiserver 等客户端使用--initial-cluster-tokenetcd-cluster-0集群令牌用于防止把两个不同集群的成员混在同一 Raft 集群里--initial-clustercontrollerhttp://127.0.0.1:2380初始成员列表只有controller一个成员即单节点集群--initial-cluster-statenew声明这是一个全新集群而非向已有集群加入--data-dir/var/lib/etcd持久化数据目录此外单元文件还体现了几个 systemd 层面的设计Typenotifyetcd 会主动通过 systemd 的 sd_notify 协议汇报就绪状态systemd 能准确判断服务真正完成启动而不是只看进程是否拉起。Restarton-failure与RestartSec5进程异常退出时 5 秒后自动重启提供基本的自愈能力。全部地址绑定在127.0.0.1由于本教程把控制面组件全部部署在同一台server机器上etcd 只需对本地回环接口可达即可这也避免了数据端口暴露到网络。值得对照的一点是从 units/kube-apiserver.service 的--etcd-servershttp://127.0.0.1:2379参数可以看出API Server 正是通过 2379 客户端端口访问本集群的——两个服务文件在端口约定上是互相咬合的。同时可以看到这个用于教学的单节点集群在 peer 与 client 连接上都使用http://未启用 TLS 与客户端证书认证教程目标是学习引导流程本身生产环境通常还会加上--cert-file、--key-file、--client-cert-auth等参数来启用 TLS 与身份认证。启动 etcd 服务把单元文件就位后重载 systemd 配置并启用、启动服务{ systemctl daemon-reload systemctl enable etcd systemctl start etcd }daemon-reload让 systemd 重新读取/etc/systemd/system/下新增的单元文件enable使 etcd 在机器重启后随multi-user.target自动拉起start立即启动服务。验证列出 etcd 集群成员使用此前一并拷贝安装的etcdctl列出集群成员etcdctl member list预期输出形如6702b0a34e2cfd39, started, controller, http://127.0.0.1:2380, http://127.0.0.1:2379, false输出各字段的含义6702b0a34e2cfd39成员 ID十六进制由 etcd 在成员加入时分配started成员状态正常、已参与 Raft 集群controller与--name controller对应的成员名http://127.0.0.1:2380该成员的 peer 地址http://127.0.0.1:2379该成员的客户端地址false非learner成员。若输出中出现unstarted或地址对不上通常意味着--initial-cluster与实际网络配置不一致可回到单元文件逐项核对。你也可以用systemctl status etcd确认进程状态配合单元文件中的RestartSec5观察异常重启行为。小结与下一步本 Lab 以四个动作完成了单节点 etcd 集群的引导拷贝二进制与单元文件 → 安装二进制并配置证书/数据目录 → 通过 systemd 单元启动服务 → 用etcdctl member list验证成员状态。etcd 就绪后Kubernetes 集群状态的持久化后端就位了。按照教程顺序下一步是 Bootstrapping the Kubernetes Control Plane在server上部署 kube-apiserver、kube-scheduler 与 kube-controller-manager其中kube-apiserver会通过--etcd-servershttp://127.0.0.1:2379见 units/kube-apiserver.service直接对接本实验建立的 etcd 实例。适用前提与限制本篇操作基于本仓库锁定的组件版本Kubernetes v1.32.3 / etcd v3.6.0-rc.3见 downloads-amd64.txt操作系统为 Debian 12 (bookworm)全部命令以 root 用户执行且控制面组件与 etcd 同机部署于server。教程结果不应视为生产就绪方案生产集群在成员数、TLS 与备份策略上均需另行设计。【免费下载链接】kubernetes-the-hard-wayBootstrap Kubernetes the hard way. No scripts.项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-the-hard-way创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes The Hard Way：从零引导单节点 etcd 集群（kthw Lab 07 实战解析）
Kubernetes The Hard Way从零引导单节点 etcd 集群kthw Lab 07 实战解析【免费下载链接】kubernetes-the-hard-wayBootstrap Kubernetes the hard way. No scripts.项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-the-hard-way在 Kubernetes The Hard Way 教程中Kubernetes 各控制面组件本身都是无状态的——它们的所有集群状态Node、Service、Deployment、Secret 等对象的真实数据都存储在一个名为 etcd 的分布式键值数据库中。本篇对应 Bootstrapping the etcd Cluster 实验带你以“无脚本、纯手工”的方式在server机器上安装并引导一个单节点 etcd 集群逐一剖析 units/etcd.service 中的每个启动参数的含义。读完本篇你将掌握etcd 二进制与 systemd 服务的部署流程、etcd 各监听端口的职责2379/2380、集群成员与数据目录的权限配置以及后续kube-apiserver如何以--etcd-servers参数接入这个数据后端。为什么 Kubernetes 需要 etcd从 README.md 的组件清单可以看到本教程使用的组件版本为kubernetes v1.32.x具体为 v1.32.3见 downloads-amd64.txtcontainerd v2.1.xcni v1.6.xetcd v3.6.x本仓库下载列表锁定为 v3.6.0-rc.3Kubernetes API Server 是唯一与 etcd 直接通信的控制面组件。kube-scheduler、kube-controller-manager等组件通过 API Server 间接读写集群状态。因此引导 etcd 是引导整个控制平面之前最关键的一步一旦 etcd 不可用集群将失去其持久化状态。本教程选择在server单机上引导一个单节点 etcd 集群足以支撑学习目的生产环境则通常需要 3 个或 5 个成员构成 Raft 集群。前置条件拷贝 etcd 二进制与 systemd 单元文件整个教程在四台 Debian 12 (bookworm) 机器上运行jumpbox、server、node-0、node-1硬件要求见 Prerequisites。etcd 的二进制文件已在 Set Up The Jumpbox 阶段从 downloads-amd64.txt或 downloads-arm64.txt统一下载并解压到jumpbox的downloads/目录下其中downloads/controller/etcdetcd 服务端二进制downloads/client/etcdctletcd 的命令行客户端工具本 Lab 的第一步是在jumpbox上把 etcd 二进制与 systemd 单元文件拷贝到server机器scp \ downloads/controller/etcd \ downloads/client/etcdctl \ units/etcd.service \ rootserver:~/之后登录server机器执行后续所有命令ssh rootserver注意本 Lab 的后续命令都必须在server机器上执行而不是jumpbox。安装 etcd 二进制在server机器上把etcd服务端与etcdctl命令行工具移动到 PATH 中的/usr/local/bin/{ mv etcd etcdctl /usr/local/bin/ }这一步完成后两个二进制都可以直接通过命令名调用。配置 etcd 服务目录与数据目录接下来创建 etcd 的配置目录与数据目录并把 TLS 证书放进配置目录{ mkdir -p /etc/etcd /var/lib/etcd chmod 700 /var/lib/etcd cp ca.crt kube-api-server.key kube-api-server.crt \ /etc/etcd/ }逐条拆解这个操作的用意/etc/etcd/存放 etcd 服务运行所需的证书等配置材料。这里复制了 Provisioning the CA and Generating TLS Certificates 实验在jumpbox生成并分发到server的三个文件ca.crtCA 根证书、kube-api-server.key与kube-api-server.crtkube-apiserver 的客户端证书/密钥对。这些证书在后续控制面组件中会被用作身份凭证。/var/lib/etcdetcd 的数据目录BBolt 数据库与 WAL 日志所在处对应 systemd 单元中的--data-dir/var/lib/etcd。chmod 700 /var/lib/etcd把数据目录权限收紧为仅 root 可读写执行。etcd 中存储着集群的全部状态其中可能包含 Secret 等敏感数据即便本教程后续用 生成数据加密配置 的 encryption-config 对其做静态加密收紧目录权限是基本的纵深防御措施。原文档还特别强调了一点etcd 集群中的每个成员必须拥有唯一的--name教程将该成员名设置为与当前计算实例的 hostname 一致本教程中为controller。这一点直接体现在下文的 systemd 单元里。深入解析 units/etcd.service 的每个启动参数把单元文件放入 systemd 目录mv etcd.service /etc/systemd/system/本仓库提供的 units/etcd.service 内容如下这也是理解 etcd 启动行为的核心[Unit] Descriptionetcd Documentationhttps://github.com/etcd-io/etcd [Service] Typenotify ExecStart/usr/local/bin/etcd \ --name controller \ --initial-advertise-peer-urls http://127.0.0.1:2380 \ --listen-peer-urls http://127.0.0.1:2380 \ --listen-client-urls http://127.0.0.1:2379 \ --advertise-client-urls http://127.0.0.1:2379 \ --initial-cluster-token etcd-cluster-0 \ --initial-cluster controllerhttp://127.0.0.1:2380 \ --initial-cluster-state new \ --data-dir/var/lib/etcd Restarton-failure RestartSec5 [Install] WantedBymulti-user.target参数逐一解析参数取值作用--namecontroller本成员在集群内的唯一标识教程要求其等于实例 hostname--initial-advertise-peer-urlshttp://127.0.0.1:2380告知集群中其他成员用哪个地址与本节点通信peer 流量--listen-peer-urlshttp://127.0.0.1:2380etcd 实际监听 peer/Raft 通信的端口2380--listen-client-urlshttp://127.0.0.1:2379etcd 实际监听客户端 API 请求的端口2379--advertise-client-urlshttp://127.0.0.1:2379对外通告的客户端接入地址供 kube-apiserver 等客户端使用--initial-cluster-tokenetcd-cluster-0集群令牌用于防止把两个不同集群的成员混在同一 Raft 集群里--initial-clustercontrollerhttp://127.0.0.1:2380初始成员列表只有controller一个成员即单节点集群--initial-cluster-statenew声明这是一个全新集群而非向已有集群加入--data-dir/var/lib/etcd持久化数据目录此外单元文件还体现了几个 systemd 层面的设计Typenotifyetcd 会主动通过 systemd 的 sd_notify 协议汇报就绪状态systemd 能准确判断服务真正完成启动而不是只看进程是否拉起。Restarton-failure与RestartSec5进程异常退出时 5 秒后自动重启提供基本的自愈能力。全部地址绑定在127.0.0.1由于本教程把控制面组件全部部署在同一台server机器上etcd 只需对本地回环接口可达即可这也避免了数据端口暴露到网络。值得对照的一点是从 units/kube-apiserver.service 的--etcd-servershttp://127.0.0.1:2379参数可以看出API Server 正是通过 2379 客户端端口访问本集群的——两个服务文件在端口约定上是互相咬合的。同时可以看到这个用于教学的单节点集群在 peer 与 client 连接上都使用http://未启用 TLS 与客户端证书认证教程目标是学习引导流程本身生产环境通常还会加上--cert-file、--key-file、--client-cert-auth等参数来启用 TLS 与身份认证。启动 etcd 服务把单元文件就位后重载 systemd 配置并启用、启动服务{ systemctl daemon-reload systemctl enable etcd systemctl start etcd }daemon-reload让 systemd 重新读取/etc/systemd/system/下新增的单元文件enable使 etcd 在机器重启后随multi-user.target自动拉起start立即启动服务。验证列出 etcd 集群成员使用此前一并拷贝安装的etcdctl列出集群成员etcdctl member list预期输出形如6702b0a34e2cfd39, started, controller, http://127.0.0.1:2380, http://127.0.0.1:2379, false输出各字段的含义6702b0a34e2cfd39成员 ID十六进制由 etcd 在成员加入时分配started成员状态正常、已参与 Raft 集群controller与--name controller对应的成员名http://127.0.0.1:2380该成员的 peer 地址http://127.0.0.1:2379该成员的客户端地址false非learner成员。若输出中出现unstarted或地址对不上通常意味着--initial-cluster与实际网络配置不一致可回到单元文件逐项核对。你也可以用systemctl status etcd确认进程状态配合单元文件中的RestartSec5观察异常重启行为。小结与下一步本 Lab 以四个动作完成了单节点 etcd 集群的引导拷贝二进制与单元文件 → 安装二进制并配置证书/数据目录 → 通过 systemd 单元启动服务 → 用etcdctl member list验证成员状态。etcd 就绪后Kubernetes 集群状态的持久化后端就位了。按照教程顺序下一步是 Bootstrapping the Kubernetes Control Plane在server上部署 kube-apiserver、kube-scheduler 与 kube-controller-manager其中kube-apiserver会通过--etcd-servershttp://127.0.0.1:2379见 units/kube-apiserver.service直接对接本实验建立的 etcd 实例。适用前提与限制本篇操作基于本仓库锁定的组件版本Kubernetes v1.32.3 / etcd v3.6.0-rc.3见 downloads-amd64.txt操作系统为 Debian 12 (bookworm)全部命令以 root 用户执行且控制面组件与 etcd 同机部署于server。教程结果不应视为生产就绪方案生产集群在成员数、TLS 与备份策略上均需另行设计。【免费下载链接】kubernetes-the-hard-wayBootstrap Kubernetes the hard way. No scripts.项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-the-hard-way创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
![Angular Signal Forms 深入解析：`[formField]` 的编译器类型检查与 Core 运行时集成机制](http://pic.xiahunao.cn/yaotu/Angular Signal Forms 深入解析：`[formField]` 的编译器类型检查与 Core 运行时集成机制)
