Kubernetes初始搭建：从环境契约到控制平面自举-北京尧图网络

1. 为什么“k8s的初始及搭建”不是一次安装而是一场认知重装很多人点开“k8s搭建教程”心里想的是下载几个二进制、跑几条命令、等个kubectl get nodes显示Ready就算搞定了。我试过三次——第一次在CentOS 7上卡在kubelet证书校验失败第二次在Ubuntu 22.04上因cgroup v2默认启用导致containerd无法拉镜像第三次用kubeadm init成功了但kubectl get pods -A里coredns始终是Pending查日志发现是CNI插件没配配了又因网络插件版本和k8s主版本不匹配触发了Pod调度死锁。这根本不是“搭环境”而是把整个分布式系统运行逻辑在脑子里重新跑一遍。k8s的“初始”本质是初始化你对声明式编排、控制平面与数据平面分离、节点生命周期自治、网络与存储抽象层解耦这四根支柱的理解。它不像装MySQL那样有明确的“服务启动成功”标志它的健康状态是动态收敛的etcd集群要同步、apiserver要响应、scheduler要持续打分、controller-manager要反复调谐、kubelet要上报心跳、CNI要分配IP、CSI要挂载卷——任何一个环节卡住整个系统就停在“半活”状态。而市面上90%的入门教程只告诉你kubeadm init怎么敲却从不解释为什么必须先关swap为什么--pod-network-cidr不能随便改为什么kubeadm join命令里带的token有效期只有24小时这些不是配置细节而是k8s设计哲学的具象投射。关键词里虽然空着但所有实操者都会撞上的核心词其实是control plane、data plane、etcd quorum、CNI plugin、kubeconfig context、node taints、static pod manifest。它们不是术语列表而是你每次执行命令时背后真实运转的齿轮。比如kubeadm init生成的/etc/kubernetes/manifests/kube-apiserver.yaml它不是配置文件而是k8s用“自己管理自己”的第一个证据——apiserver这个核心组件居然是由kubelet以static pod方式启动的。这种自举机制决定了你后续所有排错都必须从/etc/kubernetes/manifests/目录开始翻日志而不是去systemd里查服务状态。所以这篇内容不叫“k8s搭建教程”它是一份初始阶段的认知地图与排错罗盘。我会带你从零开始亲手构建一个最小可行集群3节点1 master 2 worker但每一步都拆解背后的“为什么”并把我在某实验室部署模拟项目X时踩过的17个典型坑按发生概率排序列出来。你不需要记住所有命令但必须理解每个参数在控制平面上触发了什么动作。毕竟真正的“搭建完成”是你看到kubectl get nodes输出Ready后还能准确说出此刻etcd里存了几条key、kube-scheduler正在监听哪个API资源、以及为什么那个NotReady节点其实只是kubelet没上报NodeCondition。2. 环境准备被99%教程忽略的底层契约k8s不是黑盒应用它对宿主机操作系统、内核参数、容器运行时有明确的契约要求。跳过这步直接kubeadm init等于在流沙上盖楼——表面能立住但任何风吹草动比如内核升级、Docker更新都会让集群无声崩塌。2.1 操作系统与内核稳定压倒一切某高校在教学环境中曾用Ubuntu 24.04 LTS部署k8s 1.28结果发现containerd 1.7.x与新内核的io_uring接口存在兼容问题导致Pod创建延迟高达8秒。最终回退到Ubuntu 22.04 LTS kernel 5.15.0-107-generic才稳定。这不是偶然而是k8s官方支持矩阵的硬性约束k8s 1.28明确要求Linux kernel ≥ 4.19但生产推荐使用5.4因为cgroup v2的完整支持、memory cgroup v2的OOM killer优化、以及io cgroup v2的I/O限速精度全依赖这个分水岭。提示用uname -r确认内核版本后务必执行cat /proc/sys/fs/cgroup/cloned_subtree。若返回0说明cgroup v1模式若返回1则为v2。k8s 1.26已全面支持cgroup v2但某些旧版containerd如1.6.x会因v2的memory.max字段解析异常导致OOMKilled误报。此时需在/etc/default/grub中添加systemd.unified_cgroup_hierarchy0并update-grub reboot强制降级到v1。2.2 网络与防火墙别让iptables抢了k8s的活k8s的网络模型建立在“每个Pod有独立IP、可被集群内任意节点直接访问”之上。这意味着宿主机防火墙必须放行关键端口且不能与k8s的iptables规则冲突。首先关闭firewalld或ufw# Ubuntu系 sudo ufw disable # CentOS/RHEL系 sudo systemctl stop firewalld sudo systemctl disable firewalld然后手动放行k8s必需端口注意这是master节点的最小集合端口协议用途是否必须6443TCPkube-apiserver HTTPS端口✅ 所有节点10250TCPkubelet API端口用于metrics、logs✅ 所有节点10259TCPkube-scheduler healthz端口✅ master节点10257TCPkube-controller-manager healthz端口✅ master节点2379-2380TCPetcd server client端口✅ master节点仅etcd成员注意很多教程让你iptables -P FORWARD ACCEPT这看似简单实则埋雷。k8s的kube-proxy会自动管理FORWARD链规则手动ACCEPT会导致网络策略NetworkPolicy失效。正确做法是保留默认DROP让kube-proxy接管——它会在KUBE-FORWARD链中插入精确规则。验证方法iptables -t filter -L FORWARD | grep KUBE应看到类似KUBE-FORWARD all -- anywhere anywhere的跳转。2.3 容器运行时containerd才是现代k8s的基石Docker Engine已被k8s弃用dockershim移除现在必须用containerd或CRI-O。某公司迁移时坚持用Docker结果在k8s 1.24升级后所有节点kubelet全部报failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: systemd is different from docker cgroup driver: cgroupfs。根源在于Docker默认用cgroupfs驱动而k8s推荐systemd驱动以匹配systemd init系统。containerd的配置必须显式指定驱动# 编辑 /etc/containerd/config.toml [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] ... [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true # 关键必须设为true然后重启sudo systemctl restart containerd。验证驱动是否一致# 查看kubelet配置 ps aux | grep kubelet | grep cgroup-driver # 应输出 --cgroup-driversystemd # 查看containerd实际驱动 sudo ctr -n k8s.io info | grep runtime # 应显示 runc 的 systemdCgroup: true2.4 基础依赖swap、modprobe与hostname的三重校验Swap必须关闭k8s调度器假设节点内存是“硬上限”swap会破坏此假设。sudo swapoff -a后还要注释/etc/fstab中swap行否则重启失效。内核模块加载br_netfilter桥接网络过滤、overlayoverlayfs存储驱动必须预加载sudo modprobe br_netfilter overlay echo br_netfilter | sudo tee -a /etc/modules echo overlay | sudo tee -a /etc/modulesHostname唯一性k8s用hostname作为NodeName。sudo hostnamectl set-hostname node1后必须确保/etc/hosts中该hostname能解析到本机IP如192.168.1.10 node1。否则kubeadm join会因证书CN不匹配失败。这四步做完你得到的不是一个“能跑命令”的机器而是一个符合k8s运行契约的洁净沙盒。此时执行lsmod | grep -E (br_netfilter|overlay)应有输出free -h中swap为0cat /proc/sys/net/bridge/bridge-nf-call-iptables返回1——这些才是k8s真正需要的“初始状态”。3. 控制平面初始化kubeadm init的每一行都在做什么kubeadm init不是魔法它是kubeadm将k8s控制平面组件apiserver、scheduler、controller-manager、etcd以static pod方式部署到master节点的过程。理解每一步才能在init失败时精准定位。3.1 初始化命令的参数深意标准命令sudo kubeadm init \ --kubernetes-versionv1.28.2 \ --pod-network-cidr10.244.0.0/16 \ --service-cidr10.96.0.0/12 \ --cri-socketunix:///run/containerd/containerd.sock \ --ignore-preflight-errorsNumCPU,Mem逐参数拆解--kubernetes-version指定k8s版本。必须与kubeadm版本严格匹配。kubeadm version输出1.28.2则此处必须为v1.28.2。若填stable-1.28kubeadm会自动解析但解析结果可能滞后于最新补丁版如解析为v1.28.0导致后续kubeadm upgrade失败。某实验室曾因此在安全补丁升级时因版本号不一致触发etcd数据迁移失败。--pod-network-cidr这是CNI插件的IP地址池不是k8s自身分配的网段。它必须与后续安装的CNI插件配置完全一致。例如Flannel默认用10.244.0.0/16Calico用192.168.0.0/16。如果此处填10.244.0.0/16但装Calico时没修改其calico.yaml中的CALICO_IPV4POOL_CIDR则所有Pod会获得错误网段IP跨节点通信彻底中断。--service-cidrService ClusterIP的地址池。默认10.96.0.0/12即10.96.0.0到10.111.255.255共约100万个IP。此网段绝不能与宿主机物理网络、Pod网络、公司内网重叠。某公司用192.168.1.0/24作物理网段却将--service-cidr设为192.168.0.0/16导致Service IP与办公电脑IP冲突kubectl exec到Pod后无法访问公司OA系统。--cri-socket明确指定containerd socket路径。kubeadm会自动探测但多运行时环境如同时装Docker和containerd下易出错。unix:///run/containerd/containerd.sock是containerd标准路径unix:///var/run/dockershim.sock是Docker旧路径已废弃。--ignore-preflight-errors跳过预检错误。NumCPUCPU核数2、Mem内存1700MB是k8s最低要求。生产环境严禁跳过但实验环境可临时忽略。切勿忽略Swap、CGroup等关键错误——它们代表环境不合规。3.2 init过程的五个关键阶段执行kubeadm init后你会看到类似输出[init] Using Kubernetes version: v1.28.2 [preflight] Running pre-flight checks ... [certs] Using certificateDir folder /etc/kubernetes/pki [certs] Generating ca certificate and key [certs] Generating apiserver certificate and key ... [kubeconfig] Using kubeconfig folder /etc/kubernetes [kubeconfig] Writing admin.conf kubeconfig file [kubeconfig] Writing kubelet.conf kubeconfig file ... [control-plane] Using manifest folder /etc/kubernetes/manifests [control-plane] Creating static Pod manifest for kube-apiserver [control-plane] Creating static Pod manifest for kube-controller-manager [control-plane] Creating static Pod manifest for kube-scheduler [etcd] Creating static Pod manifest for local etcd ... [bootstraptoken] Using token: abcdef.0123456789abcdef [bootstraptoken] Configuring bootstrap tokens, cluster-info [addons] Applied essential addon: CoreDNS [addons] Applied essential addon: kube-proxy这背后是五个不可跳过的阶段Preflight Checks预检检查swap、cgroup、端口占用、内核模块等。失败时会明确提示如[ERROR Swap]: running with swap on is not supported。此时不要强行--ignore应先解决根本问题。Certificates Generation证书生成在/etc/kubernetes/pki/下生成PKI体系ca.crt/ca.key根CA用于签发所有其他证书apiserver.crt/apiserver.keyapiserver服务证书CNkubernetesSAN包含所有master IP和域名front-proxy-ca.crt/front-proxy-ca.key前端代理CA用于聚合API服务器认证sa.pub/sa.keyservice account密钥对用于Pod内Token签名关键经验kubeadm init生成的证书默认有效期为1年。生产环境必须用kubeadm certs renew all定期更新否则1年后所有组件因证书过期停止工作。某公司集群在上线13个月后突然全部NotReady排查3天才发现是/etc/kubernetes/pki/apiserver.crt过期。Kubeconfig Generation配置文件生成创建三个关键kubeconfig文件admin.conf给管理员用用户为kubernetes-admin证书指向/etc/kubernetes/pki/apiserver.crtkubelet.conf给kubelet用用户为system:node:node1证书指向/etc/kubernetes/pki/kubelet.crtcontroller-manager.conf/scheduler.conf给控制器组件用这些文件定义了“谁”user、“用什么凭证”client-certificate-data、“连哪里”server: https://192.168.1.10:6443——它们是k8s身份认证的起点。Static Pod Manifests静态Pod清单在/etc/kubernetes/manifests/下生成4个YAML文件kube-apiserver.yaml定义apiserver容器镜像、启动参数如--advertise-address192.168.1.10、volume挂载/etc/kubernetes/pki、/etc/ssl/certskube-controller-manager.yaml同理关键参数--leader-electtrue启用高可用选举kube-scheduler.yaml同样启用leader选举etcd.yaml定义etcd容器挂载/var/lib/etcd数据目录设置--initial-clusternode1https://192.168.1.10:2380这就是k8s“自举”的核心kubelet监控/etc/kubernetes/manifests/目录发现新YAML就拉起对应容器。没有apiserver时kubelet靠本地文件系统工作apiserver起来后它才开始向apiserver注册节点。Addons Installation插件安装自动部署CoreDNSDNS服务和kube-proxyService代理。CoreDNS的Deployment定义在/etc/kubernetes/manifests/coredns.yaml中它依赖kube-system命名空间和corednsServiceAccount——这些资源由kubeadm在init最后阶段通过API Server创建。3.3 init成功后的必做三件事kubeadm init输出最后会显示Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config You should now deploy a pod network to the cluster. Run kubectl apply -f [podnetwork].yaml with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/ You can now join any number of machines by running the following on each node as root: kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx这三件事缺一不可配置kubectl访问权限cp /etc/kubernetes/admin.conf到$HOME/.kube/config。否则kubectl会报The connection to the server localhost:8080 was refused——因为它默认连本地8080端口已废弃而admin.conf指定了正确的6443端口和证书。部署CNI网络插件这是init后最常卡住的环节。kubectl get pods -A会显示coredns-xxx处于Pending因为没有CNIPod无法分配IP。必须立即执行# Flannel最轻量适合学习 kubectl apply -f https://github.com/flannel-io/flannel/releases/download/v0.24.2/kube-flannel.yml # 或 Calico功能强适合生产 kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/calico.yaml部署后等待kubectl get pods -n kube-flannel或kubectl get pods -n calico-system全部Running再检查coredns状态。保存join命令kubeadm join命令中的token有效期仅24小时hash值永久有效但需配合有效token。生产环境必须用kubeadm token create --ttl 0生成永不过期token并记录kubeadm cert list中ca.crt的hash值openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2/dev/null | openssl dgst -sha256 -hex | sed s/^.* //。这三步做完你的控制平面才算真正“活”过来。此时kubectl get componentstatuses虽已弃用但仍有参考价值应显示所有组件Healthykubectl get nodes显示Ready——但这只是master节点的状态worker节点还需kubeadm join。4. 工作节点加入join命令背后的信任链建立kubeadm join不是简单的“连上master”而是worker节点与control plane之间建立双向TLS信任、完成节点注册、并获取必要凭证的完整流程。理解这个过程才能诊断join失败的12种常见原因。4.1 join命令的完整执行链在worker节点执行sudo kubeadm join 192.168.1.10:6443 \ --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx它触发以下步骤Discovery发现worker节点用--discovery-token-ca-cert-hash验证master的ca.crt真实性。它先向https://192.168.1.10:6443发起HTTPS请求拿到证书后计算SHA256哈希与传入的hash比对。若不匹配报错certificate signed by unknown authority——常见于master证书被替换如kubeadm certs renew后未更新hash或网络中间人攻击企业代理劫持SSL。TLS BootstrapTLS引导worker节点生成自己的CSRCertificate Signing Request通过/api/v1/namespaces/kube-public/configmaps/cluster-info获取master信息向apiserver提交CSR。apiserver的csrapprovingcontroller会自动批准system:node前缀的CSR前提是kubeadm init时启用了--feature-gatesRotateKubeletServerCertificatetrue1.28默认开启。Certificate Issuance证书颁发apiserver批准CSR后调用/apis/certificates.k8s.io/v1/certificatesigningrequestsAPI由kube-controller-manager的certificatesigningrequestscontroller签发kubelet-client.crt和kubelet-server.crt存入/var/lib/kubelet/pki/。Kubeconfig Generation配置生成kubeadm根据签发的证书生成/etc/kubernetes/kubelet.conf其中users[0].user.client-certificate-data指向/var/lib/kubelet/pki/kubelet-client-current.pem。Node Registration节点注册kubelet启动后用kubelet.conf连接apiserver发送POST /api/v1/nodes请求注册自身为Node对象。此时kubectl get nodes才会出现该节点。4.2 join失败的四大高频场景与诊断法场景1token过期或无效现象error execution phase preflight: couldnt validate the identity of the API Server: abort connecting to API servers after timeout of 5m0s根因token在master上已过期默认24小时或kubeadm token list中无此token。诊断在master执行kubeadm token list确认token存在且EXPIRES未过期。若过期生成新tokenkubeadm token create --ttl 2h。修复用新token重新join。场景2CA证书hash不匹配现象[discovery] Failed to request cluster-info, will try again: [Get https://192.168.1.10:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: x509: certificate signed by unknown authority]根因worker节点计算的CA证书hash与--discovery-token-ca-cert-hash不一致。诊断在master执行openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2/dev/null | openssl dgst -sha256 -hex | sed s/^.* //对比输出与join命令中的hash。修复若master证书已更新如renew必须用新hash若worker网络被代理需配置export HTTPS_PROXYhttp://proxy:8080并确保代理信任CA。场景3kubelet未启动或配置错误现象[preflight] Running pre-flight checks卡住或[kubelet-start] Writing kubelet configuration to file /var/lib/kubelet/config.yaml后无响应。根因kubelet服务未运行或/var/lib/kubelet/config.yaml中cgroupDriver与containerd不一致。诊断sudo systemctl status kubelet查看状态sudo journalctl -u kubelet -n 100 --no-pager查日志sudo cat /var/lib/kubelet/config.yaml | grep cgroupDriver确认值为systemd。修复sudo systemctl daemon-reload sudo systemctl restart kubelet若cgroupDriver错误在/var/lib/kubelet/config.yaml中修改并重启。场景4网络不通或端口被拒现象[discovery] Failed to request cluster-info... dial tcp 192.168.1.10:6443: i/o timeout根因worker到master的6443端口不通防火墙、网络策略、路由错误。诊断在worker执行telnet 192.168.1.10 6443或nc -vz 192.168.1.10 6443。若不通检查master防火墙、worker路由表、物理网络连通性。修复开放端口或修复网络路径。4.3 join后的节点状态演进成功join后节点状态会经历NotReady→Readykubelet启动并上报心跳。Ready,SchedulingDisabled节点被kubectl cordon隔离不再调度新Pod。NotReady长期kubelet未上报NodeCondition常见于/var/lib/kubelet/pki/证书损坏或/etc/kubernetes/kubelet.conf权限错误应为600。验证节点状态# 查看节点基础信息 kubectl get nodes -o wide # 查看节点详细条件 kubectl describe node worker1 | grep -A 10 Conditions: # 查看kubelet日志在worker节点 sudo journalctl -u kubelet -n 50 --no-pager | grep -E (Failed|Error|Warning)某实验室曾遇到worker节点kubectl get nodes显示Ready但kubectl get pods -A看不到任何Pod。排查发现kubectl describe node中Conditions显示DiskPressureTrue原因是/var/lib/kubelet所在磁盘剩余空间15%。k8s默认触发驱逐但Pod未被删除——因为eviction-hard参数未配置。解决方案kubectl edit node worker1在spec中添加evictionHard: {memory.available: 500Mi, nodefs.available: 10%}或在kubelet启动参数中加--eviction-hardmemory.available500Mi,nodefs.available10%。5. 初始集群验证从kubectl get nodes到真实业务负载kubectl get nodes显示Ready只是万里长征第一步。真正的“搭建完成”是集群能稳定承载你预期的业务负载。这需要一套分层验证方案覆盖网络、存储、调度、安全四个维度。5.1 网络连通性验证不止是ping通k8s网络验证必须跨越三层Pod-to-Pod、Pod-to-Service、Service-to-External。Pod-to-Pod验证跨节点# 在master节点创建busybox测试Pod kubectl run busybox1 --imagebusybox:1.35 --restartNever -- sleep 3600 kubectl run busybox2 --imagebusybox:1.35 --restartNever -- sleep 3600 # 获取Pod IP kubectl get pods -o wide # 从busybox1 ping busybox2需在同一命名空间 kubectl exec busybox1 -- ping -c 3 busybox2-IP若失败检查CNI插件日志kubectl logs -n kube-flannel flannel-ds-xxxxx -c kube-flannelFlannel或kubectl logs -n calico-system calico-node-xxxxx -c calico-nodeCalico。Pod-to-Service验证# 创建一个nginx Deployment和Service kubectl create deployment nginx --imagenginx:1.25 kubectl expose deployment nginx --port80 --typeClusterIP # 获取Service ClusterIP kubectl get service nginx # 从busybox1访问Service kubectl exec busybox1 -- wget -qO- http://nginx-ClusterIP:80 | head -5若超时检查kube-proxy是否正常kubectl get pods -n kube-system -l k8s-appkube-proxy并验证iptables规则sudo iptables -t nat -L KUBE-SERVICES | grep nginx。Service-to-External验证DNS解析# 在busybox1中解析k8s内部Service kubectl exec busybox1 -- nslookup kubernetes.default.svc.cluster.local # 解析外部域名 kubectl exec busybox1 -- nslookup google.com若内部解析失败CoreDNS Pod可能未就绪若外部解析失败检查/etc/resolv.conf中nameserver是否为CoreDNS ClusterIPkubectl get service -n kube-system kube-dns。5.2 存储可用性验证从emptyDir到PV初始集群默认不提供持久化存储但emptyDir和hostPath必须可用。emptyDir验证kubectl apply -f - EOF apiVersion: v1 kind: Pod metadata: name: test-emptydir spec: containers: - name: writer image: ubuntu:22.04 command: [/bin/sh, -c] args: [echo hello /cache/test.txt sleep 3600] volumeMounts: - name: cache-volume mountPath: /cache volumes: - name: cache-volume emptyDir: {} EOF # 检查Pod是否Running kubectl get pods test-emptydir # 进入Pod验证文件存在 kubectl exec test-emptydir -- ls /cachehostPath验证需提前在worker节点创建目录# 在worker节点执行 sudo mkdir -p /mnt/data # 创建Pod挂载hostPath kubectl apply -f - EOF apiVersion: v1 kind: Pod metadata: name: test-hostpath spec: containers: - name: reader image: ubuntu:22.04 command: [/bin/sh, -c] args: [cat /data/test.txt sleep 3600] volumeMounts: - name:># 部署一个消耗1核CPU的Pod kubectl run stress-cpu --imagepolinux/stress-ng -- --cpu 1 --timeout 60s # 部署一个消耗512Mi内存的Pod kubectl run stress-mem --imagepolinux/stress-ng -- --vm 1 --vm-bytes 512M --timeout 60s # 观察Pod状态和节点资源 kubectl top nodes kubectl describe pod stress-cpu若Pod长时间Pending检查kubectl describe node中的Events常见原因资源不足Insufficient cpu、污点Taints: node-role.kubernetes.io/control-plane:NoSchedule、或亲和性不匹配。5.4 安全基线验证最小权限原则落地初始集群默认开启RBAC但需验证最小权限是否生效# 创建一个只读ServiceAccount kubectl create serviceaccount readonly-user kubectl create clusterrolebinding readonly-binding \ --clusterroleview \ --serviceaccountdefault:readonly-user # 获取该SA的token TOKEN$(kubectl get secret $(kubectl get serviceaccount readonly-user -o jsonpath{.secrets[0].name}) -o jsonpath{.data.token} | base64 -d) # 用该token访问API curl -k -H Authorization: Bearer $TOKEN https://192.168.1.10:6443/api/v1/namespaces/default/pods # 尝试写操作应失败 curl -k -X POST -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ --data {apiVersion:v1,kind:Pod,metadata:{name:test}} \ https://192.168.1.10:6443/api/v1/namespaces/default/pods若写操作成功则RBAC未生效需检查kube-apiserver.yaml中是否启用了--authorization-modeNode,RBAC。6. 初始后的第一课如何让集群“活”得更久搭建完成不是终点而是运维的起点。某实验室的模拟项目X集群在上线第7天凌晨自动宕机日志显示etcd进程OOM被kill。根因是etcd数据目录/var/lib/etcd所在磁盘被/var/log/journal日志占满。这提醒我们初始搭建必须包含“生存保障”配置。6.1 etcd数据目录监控与清理etcd是k8s的“

Kubernetes初始搭建：从环境契约到控制平面自举

相关推荐

Windows主机痕迹管控：从日志审计到应急响应的闭环方案

从模糊代号‘rea‘到前端工程化：项目需求拆解实战

低数据无人机射频识别：单次生成式模型如何破解样本荒

更多资讯

Monitoring靶机实战：从SQL注入到sudo提权的完整渗透攻击链

VulnHub Monitoring靶机实战：从SQL注入到密码复用提权

Hack World 1靶场实战：SQL注入布尔盲注手工与自动化脚本

Mac上Homebrew换源全攻略：解决brew install卡顿与更新失败

任务编排系统规划器设计：状态空间建模与搜索策略全解析

dhtmlxGantt甘特图组件库详解：从基础配置到二次开发实战

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？