Kubernetes The Hard Way 控制面引导实战从零启动 kube-apiserver、Scheduler 与 Controller Manager【免费下载链接】kubernetes-the-hard-wayBootstrap Kubernetes the hard way. No scripts.项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-the-hard-way本文基于 kubernetes-the-hard-way 项目的 08-bootstrapping-kubernetes-controllers.md 实验文档完整讲解如何在单节点server机器上引导 Kubernetes 控制平面安装 kube-apiserver、kube-scheduler、kube-controller-manager 三大组件配置各自的 systemd 单元与 kubeconfig启动并验证集群 API 入口并为 API Server 到 Kubelet 的通信配置 RBAC 授权。读完后你将掌握控制平面组件的落盘布局、关键启动参数etcd 端点、加密配置、ServiceAccount 签名密钥、集群 CIDR 等的来源与作用以及控制平面就绪后的两种验证手段。实验背景控制平面在 Hard Way 中的位置kubernetes-the-hard-way 的核心目标是不用任何脚本地手动搭建一个可运行的 Kubernetes 集群v1.32.xcontainerd v2.1.xetcd v3.6.xCNI v1.6.x见 README.md。到本实验为止前置工作已经完成CA 与全部 TLS 证书已在 04 章 生成包括ca.crt/ca.key、kube-api-server.crt/.key、service-accounts.crt/.key各组件的 kubeconfigadmin.kubeconfig、kube-controller-manager.kubeconfig、kube-scheduler.kubeconfig等已在 05 章 生成数据加密配置 encryption-config.yaml 已在 06 章 生成etcd 集群已在 07 章 启动并监听127.0.0.1:2379。本实验在server机器上安装三个控制平面组件Kubernetes API Server、Scheduler、Controller Manager。整个控制平面运行在单节点上这是 Hard Way 教学集群的标准拓扑。前置步骤从 jumpbox 拷贝二进制与配置文件本实验的起点是jumpbox。先登录 jumpbox将 4 个二进制文件和 3 个 systemd 单元文件、2 个配置文件一次性拷贝到serverscp \ downloads/controller/kube-apiserver \ downloads/controller/kube-controller-manager \ downloads/controller/kube-scheduler \ downloads/client/kubectl \ units/kube-apiserver.service \ units/kube-controller-manager.service \ units/kube-scheduler.service \ configs/kube-scheduler.yaml \ configs/kube-apiserver-to-kubelet.yaml \ rootserver:~/这里涉及的仓库文件都可在当前项目中直接查看文件作用units/kube-apiserver.serviceAPI Server 的 systemd 单元承载全部启动参数units/kube-controller-manager.serviceController Manager 的 systemd 单元units/kube-scheduler.serviceScheduler 的 systemd 单元configs/kube-scheduler.yamlScheduler 的KubeSchedulerConfiguration声明式配置configs/kube-apiserver-to-kubelet.yaml后文 RBAC 部分使用的 ClusterRole/ClusterRoleBinding二进制来自 downloads-amd64.txtARM64 架构对应 downloads-arm64.txt中列出的dl.k8s.io/v1.32.3官方发布产物在 02 章 jumpbox 实验中已经下载解压到downloads/目录。之后切换到server机器执行后续所有命令ssh rootserverProvision 控制平面落盘布局与二进制安装创建 Kubernetes 配置目录mkdir -p /etc/kubernetes/config该目录用于存放 Scheduler 的声明式配置文件。注意 Hard Way 的落盘约定/etc/kubernetes/config放组件的 YAML 配置/var/lib/kubernetes/放证书、kubeconfig 和加密配置属于状态/凭证类文件/etc/systemd/system/放单元文件。安装控制平面二进制{ mv kube-apiserver \ kube-controller-manager \ kube-scheduler kubectl \ /usr/local/bin/ }4 个二进制统一放入/usr/local/bin/。kubectl在此安装是因为后面的验证步骤需要用它在server本机直接调用 API尚未配置远端访问那在 10 章完成。配置 Kubernetes API Server先把证书与加密配置集中到/var/lib/kubernetes/{ mkdir -p /var/lib/kubernetes/ mv ca.crt ca.key \ kube-api-server.key kube-api-server.crt \ service-accounts.key service-accounts.crt \ encryption-config.yaml \ /var/lib/kubernetes/ }再落 systemd 单元文件mv kube-apiserver.service \ /etc/systemd/system/kube-apiserver.serviceAPI Server 是控制平面中唯一直接面对外部的组件其单元文件 units/kube-apiserver.service 中的启动参数值得逐一理解存储层--etcd-servershttp://127.0.0.1:2379指向本机 etcd07 章启动未启用 TLS 的本地回环连接--encryption-provider-config/var/lib/kubernetes/encryption-config.yaml启用 Secret 静态加密对应的 encryption-config.yaml 对secrets资源使用aescbc密钥由ENCRYPTION_KEY环境变量注入identity双 provider。认证--client-ca-file/var/lib/kubernetes/ca.crt只信任本项目 CA 签发的客户端证书--tls-cert-file/--tls-private-key-file指定 API Server 自身的服务端证书。授权--authorization-modeNode,RBAC同时启用 Node 授权器和 RBAC 授权器。ServiceAccount 令牌体系--service-account-key-file/var/lib/kubernetes/service-accounts.crt与--service-account-signing-key-file/var/lib/kubernetes/service-accounts.key组成签发/验证 JWT 的密钥对--service-account-issuerhttps://server.kubernetes.local:6443声明令牌 issuer三者共同决定工作负载身份令牌能否通过 API Server 校验。准入插件--enable-admission-pluginsNamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota启用六个基础准入控制器从源码结构看这套组合是 Kubernetes 长期以来的默认准入集合保证命名空间生命周期、Node 越权限制、资源配额等基线策略始终生效。与 Kubelet 的通信--kubelet-certificate-authority/var/lib/kubernetes/ca.crt加--kubelet-client-certificate/--kubelet-client-key让 API Server 能反向调用各节点 Kubelet 的 10250 端口后续 RBAC 部分正是为这条链路授权。可观测性--audit-log-maxage30、--audit-log-maxbackup3、--audit-log-maxsize100、--audit-log-path/var/log/audit.log配置审计日志轮转--v2输出 2 级别日志Restarton-failure加RestartSec5保证崩溃后 5 秒自动拉起。其余参数如--allow-privilegedtrue允许特权容器、--bind-address0.0.0.0监听所有网卡供后续 worker 节点接入、--service-node-port-range30000-32767NodePort 分配范围也都是典型生产参数。配置 Kubernetes Controller ManagerController Manager 通过 kubeconfig 以客户端身份访问 API Server因此只需把 05 章生成的 kubeconfig 就位mv kube-controller-manager.kubeconfig /var/lib/kubernetes/然后落单元文件mv kube-controller-manager.service /etc/systemd/system/其单元文件 units/kube-controller-manager.service 的关键参数--kubeconfig/var/lib/kubernetes/kube-controller-manager.kubeconfig身份来自 05 章为system:kube-controller-manager用户生成的客户端证书与集群信息--cluster-cidr10.200.0.0/16Pod 网段NetworkPolicy 控制器依赖它做校验--service-cluster-ip-range10.32.0.0/24Service ClusterIP 网段必须与后续 09 章 kube-proxy 的配置一致--cluster-signing-cert-file/var/lib/kubernetes/ca.crt与--cluster-signing-key-file/var/lib/kubernetes/ca.keyController Manager 使用集群 CA 为节点客户端证书自动续签CSR 审批链路的签名方--service-account-private-key-file/var/lib/kubernetes/service-accounts.key必须与 API Server 的--service-account-signing-key-file相同否则签发的 ServiceAccount 令牌将无法通过 API Server 校验--use-service-account-credentialstrue各控制器使用各自命名空间的 ServiceAccount 凭证调用 API而非统一使用控制器自身的身份。配置 Kubernetes Scheduler同样先把 kubeconfig 落位mv kube-scheduler.kubeconfig /var/lib/kubernetes/与另外两个组件不同Scheduler 采用声明式配置文件 最小命令行的方式。先把 configs/kube-scheduler.yaml 移动到本实验开头创建的配置目录mv kube-scheduler.yaml /etc/kubernetes/config/再落单元文件mv kube-scheduler.service /etc/systemd/system/Scheduler 的配置文件内容是完整的KubeSchedulerConfigurationapiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /var/lib/kubernetes/kube-scheduler.kubeconfig leaderElection: leaderElect: true两点值得注意其一clientConnection.kubeconfig声明了调度器访问 API 的身份05 章生成的kube-scheduler.kubeconfig替代了旧版本用--kubeconfig命令行参数的方式其二leaderElect: true开启 leader 选举为将来控制平面多副本高可用预留能力。而 units/kube-scheduler.service 中只剩两个参数--config/etc/kubernetes/config/kube-scheduler.yaml指向该文件--v2设定日志级别——这正是能声明的配置一律写进 KubeSchedulerConfiguration的现代配置风格。启动控制平面服务并观察状态三个单元就位后重载 systemd 并一次性启动{ systemctl daemon-reload systemctl enable kube-apiserver \ kube-controller-manager kube-scheduler systemctl start kube-apiserver \ kube-controller-manager kube-scheduler }API Server 完全初始化最多需要约 10 秒验证前请先等待。状态排障三板斧# 快速判断组件是否处于 active systemctl is-active kube-apiserver # 查看带进程信息与最近日志的状态摘要 systemctl status kube-apiserver # 查看完整 journal 日志 journalctl -u kube-apiserver三个组件的Restarton-failure与RestartSec5意味着瞬时故障会自动恢复但持续失败时上述命令尤其是journalctl是定位问题的第一入口。验证控制平面kubectl cluster-info控制平面组件起来后用kubectl做第一次端到端验证在server机器上kubectl cluster-info \ --kubeconfig admin.kubeconfig期望输出Kubernetes control plane is running at https://127.0.0.1:6443这一步走通了完整链路admin.kubeconfig携带管理员客户端证书 → API Server 完成客户端认证与Node,RBAC授权 → 返回聚合的集群信息。能打印出 6443 端口的地址说明 TLS、CA 信任链、etcd 后端与 RBAC 授权均工作正常。为 Kubelet 授权配置 RBAC这一节解决控制平面与数据平面的最后一道授权关口允许 API Server 代管理员访问各 worker 节点的 Kubelet API10250 端口。访问 Kubelet API 是获取 Pod 日志、节点指标和 exec 进入容器的前提。本教程在 09 章会将 Kubelet 的--authorization-mode设为Webhook模式。Webhook 模式通过 SubjectAccessReview API 向 API Server 请求授权判定因此必须为 API Server 自身声明它有权调用 Kubelet API的规则否则所有日志、metrics、exec 请求都会被 Kubelet 拒绝。该命令影响整个集群只需在server机器上执行一次ssh rootserver创建system:kube-apiserver-to-kubeletClusterRolekubectl apply -f kube-apiserver-to-kubelet.yaml \ --kubeconfig admin.kubeconfig仓库中的 configs/kube-apiserver-to-kubelet.yaml 包含两个资源理解它们的结构比记住命令更有价值ClusterRolesystem:kube-apiserver-to-kubelet核心规则针对 core 组apiGroups: []下的五个子资源——nodes/proxy通用代理到 Kubelet、nodes/stats节点统计、nodes/logPod 日志、nodes/specPod spec 获取、nodes/metrics节点指标动词为*即完全放行。ClusterRoleBindingsystem:kube-apiserver把上述 ClusterRole 绑定到kind: User, name: kubernetes的用户。注意绑定的是用户而非 ServiceAccount——因为管理员通过admin.kubeconfig访问 API Server 时认证身份是 04 章签发的kubernetes用户Kubelet 侧的 Webhook 授权正是以该用户身份发起 SubjectAccessReview 的。元数据上的rbac.authorization.kubernetes.io/autoupdate: true注解与kubernetes.io/bootstrapping: rbac-defaults标签表明这是 Kubernetes 内置的默认 RBAC 资源之一与发行版内置的system:kube-apiserver规则保持同构。验证 API 可达性控制平面至此完全就绪。切回jumpbox做跨机验证直接对 6443 端口的/version端点发起带 CA 校验的 HTTPS 请求curl --cacert ca.crt \ https://server.kubernetes.local:6443/version期望返回类似本教程版本基线为 v1.32.3{ major: 1, minor: 32, gitVersion: v1.32.3, gitCommit: 32cc146f75aad04beaaa245a7157eb35063a9f99, gitTreeState: clean, buildDate: 2025-03-11T19:52:21Z, goVersion: go1.23.6, compiler: gc, platform: linux/arm64 }--cacert ca.crt说明请求方信任的是本项目自建 CA 而非公网 CA能收到 JSON 响应代表 DNSserver.kubernetes.local、API Server TLS 监听--bind-address0.0.0.0、服务端证书与客户端认证链路全部打通。小结与下一步本实验完成了控制平面的完整引导二进制落盘到/usr/local/bin/凭证与配置落盘到/var/lib/kubernetes/与/etc/kubernetes/config/三个 systemd 单元分别以全参数命令行API Server、Controller Manager和声明式配置文件Scheduler两种风格启动并通过kubectl cluster-info与curl /version两级验证确认集群 API 入口可用最后用system:kube-apiserver-to-kubeletClusterRole 与system:kube-apiserverClusterRoleBinding 为 Kubelet 的 Webhook 授权模式铺平道路。下一步是 09 章Bootstrapping the Kubernetes Worker Nodes在两个 worker 机器上安装 kubelet 与 kube-proxy让集群拥有第一个可调度 Pod 的数据平面。【免费下载链接】kubernetes-the-hard-wayBootstrap Kubernetes the hard way. No scripts.项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-the-hard-way创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考