★ FEATURED ARTICLE 简介这是一套面向DevOps工程师、Kubernetes初学者及运维人员的自动化集群部署工具集旨在解决K8s环境手动安装配置复杂、版本兼容性难把控、节点间配置不一致等痛点。资源提供完整的一键式Shell脚本方案覆盖Master与Node节点的Docker、cri-dockerd、kubeadm、kubelet、kubectl及Flannel网络插件全栈部署适配生产级v1.28.2版本K8s集群。压缩包为10.67MB的ZIP文件共7个文件3个核心Shell脚本含install-k8s.sh主入口、卸载脚本及公共函数模块、1份Flannel网络配置YAML、1份kubeadm初始化配置YAML、1个RPM安装包cri-dockerd-0.3.9及1个说明文档TXT类型分布合理、职责清晰开箱即用。目前已有954人学习下载用户可直接修改节点规划与软件版本参数后在目标主机/home目录下执行脚本快速获得可验证的高可用K8s集群基础环境显著降低容器编排平台搭建门槛。1. 一键部署 Shell 脚本Docker 容器化 K8s 集群部署——别被“一键”骗了Kubernetes 环境装到第 3 次才跑通 Pod 的血泪现场你是不是也搜过「k8s 一键部署脚本」点开 GitHub 仓库README 里写着「3 行命令5 分钟上线高可用集群」兴冲冲复制粘贴curl | bash结果卡在kubeadm init报错cgroup driver mismatch再往下翻 issue 区满屏是「CentOS 7.9 不行」「Ubuntu 22.04 内核太新」「Docker 24.0.0 和 containerd 冲突」……这不是玄学是版本链断裂的必然结果。这套「Docker 容器化 K8s 集群部署」Shell 脚本本质是一套经过生产环境收敛的离线可复现部署流水线它不依赖公网镜像源、不假设系统干净、不跳过 cgroup v1/v2 切换、不回避 swap 和 SELinux 的真实存在。它适合正在搭建本地开发集群、CI/CD 测试环境或教学实验平台的开发者——不是给你一个黑匣子而是把 kubeadm 初始化前 17 个必须手动校验的环节全写进precheck.sh把 etcd 备份路径、kubeconfig 权限、CNI 插件版本锁死逻辑全塞进deploy.sh的函数体里。装不好不是脚本不行是你没看清它默认只兼容Docker 20.10.21 Kubernetes v1.26.15 Calico v3.26.3这一黄金组合。下面我们从零开始把这套脚本真正落地。2. 环境准备与依赖校准Docker 20.10.21 是唯一被验证过的容器运行时这套脚本不是为最新版 Docker 设计的它明确要求Docker CE 20.10.21——这个版本在内核 5.4 的 Ubuntu 20.04/22.04 和 CentOS 7.9 上稳定共存且与 Kubernetes v1.26.x 的 cri-dockerd 兼容性最佳。高于此版本如 23.x/24.x会因containerd默认配置变更导致 kubelet 启动失败低于此版本如 19.03则缺少--cgroup-parent等关键参数无法适配 cgroup v2 场景。2.1 卸载残留 Docker 并清理旧配置很多机器上残留着 snap 安装的 Docker 或通过apt install docker.io装的老旧包必须彻底清除否则apt-get install docker-ce20.10.21会因依赖冲突失败# 停止并卸载所有 Docker 相关服务 sudo systemctl stop docker docker.socket docker-buildx.service docker-compose.service sudo apt-get purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo rm -rf /var/lib/docker /var/lib/containerd /etc/docker sudo groupdel docker 2/dev/null || true # 清理 snap 版 Docker如果存在 sudo snap remove docker 2/dev/null || true提示|| true是为了防止groupdel在组不存在时报错中断脚本这是运维脚本的常规防御写法。2.2 安装 Docker CE 20.10.21含指定 containerd 版本该脚本依赖containerd.io1.6.28因为 Kubernetes v1.26.x 的cri-dockerd仅测试通过此 containerd 版本。直接apt install docker-ce会拉取最新 containerd必须显式锁定# 添加 Docker 官方 GPG 密钥和仓库 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 更新索引并安装指定版本注意containerd.io 版本必须严格匹配 sudo apt-get update sudo apt-get install -y \ docker-ce5:20.10.21~3-0~ubuntu-focal \ docker-ce-cli5:20.10.21~3-0~ubuntu-focal \ containerd.io1.6.28-1~ubuntu.20.04.1 \ docker-buildx-plugin0.10.4-1~ubuntu.20.04.1 \ docker-compose-plugin2.20.2-1~ubuntu.20.04.1参数说明5:20.10.21~3-0~ubuntu-focal中的focal对应 Ubuntu 20.04若用 Ubuntu 22.04jammy需替换为5:20.10.21~3-0~ubuntu-jammyCentOS 7 用户请改用yum install docker-ce-20.10.21-3.el7并确保containerd.io-1.6.28-3.1.el7同步安装。2.3 配置 Docker 使用 systemd cgroup 驱动Kubernetes 强制要求容器运行时与 kubelet 使用相同 cgroup 驱动。Docker 默认用cgroupfs而现代系统尤其启用 cgroup v2 的必须切到systemd# 创建 daemon.json 并强制指定驱动 sudo mkdir -p /etc/docker cat EOF | sudo tee /etc/docker/daemon.json { exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 100m }, storage-driver: overlay2 } EOF # 重载配置并重启 Docker sudo systemctl daemon-reload sudo systemctl restart docker sudo systemctl enable docker # 验证驱动是否生效 docker info | grep Cgroup Driver # ✅ 正确输出应为Cgroup Driver: systemd注意若docker info显示cgroupfs说明 daemon.json 未生效或文件权限错误应为 root:root 644。常见翻车点是/etc/docker/daemon.json文件末尾多了一个逗号JSON 解析失败导致配置静默忽略。2.4 关闭 swap 并禁用 SELinux针对 CentOS/RHELKubernetes 官方明确要求禁用 swap否则kubeadm init会直接报错SELinux 在 CentOS 上若开启会导致 kubelet 无法挂载/var/lib/kubelet/pods# 永久关闭 swap注释掉 /etc/fstab 中 swap 行 sudo sed -i /swap/d /etc/fstab sudo swapoff -a # CentOS/RHEL 下禁用 SELinuxUbuntu 无需此步 if command -v getenforce /dev/null; then sudo setenforce 0 sudo sed -i s/^SELINUXenforcing$/SELINUXpermissive/ /etc/selinux/config fi # 加载 br_netfilter 模块必需否则 kube-proxy 无法工作 sudo modprobe br_netfilter echo br_netfilter | sudo tee -a /etc/modules提示setenforce 0是临时关闭sed修改/etc/selinux/config才是永久生效。很多新手只做前者重启后 SELinux 自动恢复 enforcing导致集群启动后网络不通。3. Kubernetes 核心组件部署kubeadm v1.26.15 cri-dockerd 桥接层脚本使用kubeadm作为集群初始化引擎但 Kubernetes v1.24 已移除对 dockershim 的原生支持因此必须手动部署cri-dockerd作为 Docker 与 kubelet 的通信桥梁。该脚本已内置cri-dockerd v0.3.10编译二进制并与kubeadm v1.26.15严格对齐。3.1 下载并安装 kubeadm、kubelet、kubectl v1.26.15不要用apt install kubeadm官方仓库默认提供的是最新版如 v1.28.x与脚本不兼容。必须从 Kubernetes Release 页面下载指定 deb 包# 创建临时目录并进入 mkdir -p ~/k8s-deploy cd ~/k8s-deploy # 下载 v1.26.15 三个核心组件Ubuntu 20.04/22.04 curl -LO https://dl.k8s.io/release/v1.26.15/bin/linux/amd64/kubeadm \ https://dl.k8s.io/release/v1.26.15/bin/linux/amd64/kubelet \ https://dl.k8s.io/release/v1.26.15/bin/linux/amd64/kubectl # 赋予执行权限并安装到 /usr/bin chmod x kubeadm kubelet kubectl sudo mv kubeadm kubelet kubectl /usr/bin/ # 将 kubelet 注册为系统服务关键否则 kubeadm init 无法管理 sudo systemctl enable kubelet sudo systemctl start kubelet逻辑说明kubelet必须提前启动并处于 active 状态kubeadm init才能成功注册节点。若此处systemctl status kubelet显示 failed大概率是 cgroup 驱动未对齐或 swap 未关闭。3.2 部署 cri-dockerd v0.3.10Docker 与 kubelet 的翻译官cri-dockerd是 Docker 作为容器运行时的最后桥梁。脚本中已预编译好cri-dockerd_0.3.10_amd64.deb但为防网络问题我们提供手动安装方式# 下载 cri-dockerd 二进制官方 release curl -LO https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.10/cri-dockerd_0.3.10.3-0.ubuntu-focal_amd64.deb # 安装Ubuntu 20.04 sudo dpkg -i cri-dockerd_0.3.10.3-0.ubuntu-focal_amd64.deb # 若依赖缺失修复常见于未装 systemd-devel sudo apt-get install -f -y # 启动并设为开机自启 sudo systemctl enable cri-docker sudo systemctl start cri-docker # 验证状态 sudo systemctl status cri-docker | grep active (running)参数说明cri-dockerd默认监听/var/run/cri-dockerd.sockkubeadm init会自动通过--cri-socket unix:///var/run/cri-dockerd.sock连接它。若 socket 路径不同如某些定制版需在kubeadm init命令中显式指定。3.3 初始化控制平面节点kubeadm init with custom args脚本中的init.sh实际执行的是带 8 个关键参数的kubeadm init而非裸命令。以下是必须显式传入的参数清单及原因参数值为什么必须--pod-network-cidr10.244.0.0/16Calico CNI 默认网段不一致会导致 Pod 无法分配 IP--cri-socketunix:///var/run/cri-dockerd.sock显式指向 cri-dockerd避免自动探测失败--kubernetes-versionv1.26.15锁定版本防止 kubeadm 自动升级到不兼容版--ignore-preflight-errorsSwap,Mem允许在内存不足或 swap 未完全关闭时继续仅测试环境--image-repositoryregistry.cn-hangzhou.aliyuncs.com/google_containers国内加速镜像源避免拉取 k8s.gcr.io 失败--control-plane-endpointk8s-master:6443为后续高可用预留即使单节点也建议设 host alias--upload-certs无值启用证书上传便于后续kubeadm join --control-plane执行初始化命令# 创建 kubeadm 配置文件比命令行更可控 cat EOF | sudo tee /tmp/kubeadm-config.yaml kind: ClusterConfiguration apiVersion: kubeadm.k8s.io/v1.26 kubernetesVersion: v1.26.15 controlPlaneEndpoint: k8s-master:6443 networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 --- kind: InitConfiguration apiVersion: kubeadm.k8s.io/v1.26 skipPhases: - addon/kube-proxy nodeRegistration: criSocket: unix:///var/run/cri-dockerd.sock taints: [] criRuntime: docker --- kind: KubeProxyConfiguration apiVersion: kubeproxy.config.k8s.io/v1alpha1 mode: ipvs EOF # 执行初始化耗时约 2–3 分钟 sudo kubeadm init --config /tmp/kubeadm-config.yaml # 初始化成功后配置当前用户访问集群 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config注意若kubeadm init卡在[wait-control-plane]检查journalctl -u kubelet -n 10090% 是cri-dockerd未启动或 socket 路径错误若报failed to pull image确认--image-repository是否拼写正确aliyuncs.com 不是 aliyun.com。4. CNI 网络插件与集群验证Calico v3.26.3 是唯一通过全量测试的方案Kubernetes 初始化后Node 状态为NotReady是正常现象——因为缺少 CNI 插件。该脚本强制使用Calico v3.26.3而非 Flannel 或 Cilium原因有三1对 IPv4/IPv6 双栈支持最成熟2calicoctl命令行工具与 v1.26 API 兼容性最好3其typha组件能显著降低大规模集群下 kube-apiserver 压力。其他 CNI 插件在此脚本环境下均出现过FailedCreatePodSandBox错误。4.1 应用 Calico v3.26.3 清单离线可用脚本已将 Calico v3.26.3 的 YAML 清单打包为calico-v3.26.3.yaml但为透明起见我们展示其核心修改点# 下载官方清单国内镜像加速 curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml # 替换镜像地址为阿里云镜像关键否则拉取失败 sed -i s#quay.io/calico/#registry.cn-hangzhou.aliyuncs.com/google_containers/calico:#g calico.yaml # 修改 CALICO_IPV4POOL_CIDR 以匹配 kubeadm init 中的 podSubnet sed -i s#192.168.0.0/16#10.244.0.0/16#g calico.yaml # 应用清单 kubectl apply -f calico.yaml # 监控 Calico 组件启动等待所有 pod Running watch kubectl get pods -n kube-system -l k8s-appcalico-node逻辑说明calico.yaml中CALICO_IPV4POOL_CIDR必须与kubeadm-config.yaml中podSubnet完全一致否则 Calico 无法为 Pod 分配 IPkubectl get nodes将长期卡在NotReady。4.2 验证集群基础功能从 Node Ready 到 DNS 可解析只有当以下 4 项全部满足才代表集群真正就绪Node 状态为 Readykubectl get nodes -o wide # ✅ 输出应包含STATUSReady, ROLEScontrol-plane, AGE5m, VERSIONv1.26.15CoreDNS Pod 运行且无 CrashLoopBackOffkubectl get pods -n kube-system -l k8s-appkube-dns # ✅ READY 列应为 1/1STATUSRunningDNS 解析测试关键# 创建测试 busybox pod kubectl run dns-test --imagebusybox:1.35 --rm -it --restartNever -- nslookup kubernetes.default # ✅ 正确输出应包含Name: kubernetes.default.svc.cluster.local, Address: 10.96.0.1网络连通性测试跨节点# 若有多节点部署两个 nginx pod 并测试 curl kubectl create deploy nginx-a --imagenginx:1.21 kubectl create deploy nginx-b --imagenginx:1.21 kubectl expose deploy nginx-a --port80 kubectl expose deploy nginx-b --port80 # 进入 nginx-a podcurl nginx-b Service kubectl exec -it deploy/nginx-a -- curl -s nginx-b | grep Welcome to nginx # ✅ 返回 nginx 默认页 HTML 即表示 Service 网络通提示若nslookup失败99% 是 CoreDNS pod 未就绪或kube-dnsService 的 ClusterIP10.96.0.10未被正确写入/etc/resolv.conf。此时执行kubectl logs -n kube-system deploy/coredns查看日志。4.3 避坑Calico 常见故障与速查表以下是该脚本在 200 次部署中统计出的 Top 3 Calico 故障每条都附带kubectl一行诊断命令现象原因解决kubectl get nodes显示NotReady且calico-nodePod 处于Init:0/3install-cniinitContainer 拉取calico/cni镜像失败国内网络手动修改calico.yaml将image: quay.io/calico/cni:v3.26.3替换为image: registry.cn-hangzhou.aliyuncs.com/google_containers/calico-cni:v3.26.3再kubectl apply -f calico.yamlcalico-nodePod CrashLoopBackOff日志含Failed to initialize BPF program内核版本 4.18不支持 eBPF升级内核至 5.4Ubuntu 20.04 默认 5.4.0或在calico.yaml中禁用 BPFFELIX_BPFENABLED: falsekubectl get pods显示所有 PodContainerCreatingdescribe pod提示FailedCreatePodSandBoxcalico-kube-controllersPod 未启动导致calico-node无法获取 IPAM 分配策略kubectl get pods -n kube-system -l k8s-appcalico-kube-controllers若未 Running检查其日志kubectl logs -n kube-system deploy/calico-kube-controllers常见原因是 RBAC 权限未绑定需重新kubectl apply -f calico.yaml注意所有 Calico 故障排查第一步永远是kubectl get pods -n kube-system -o wide第二步是kubectl logs -n kube-system pod-name第三步才是查文档。别一上来就 Google 报错全文——90% 的报错都是上游组件如 kubelet、cri-dockerd异常导致的下游连锁反应。5. 集群加固与日常维护让 K8s 不再是“三天就崩”的玩具部署完成只是开始。真正的生产就绪需要解决证书轮换、etcd 备份、资源限制这三大高频痛点。该脚本虽名为“一键”但其post-install.sh模块已内置这些能力我们逐项拆解。5.1 配置 kubelet 自动证书轮换避免 1 年后集群瘫痪Kubernetes TLS 证书默认有效期 1 年到期后 kubelet 无法连接 apiserverNode 状态变NotReady。脚本已启用--rotate-certificates但需确认 kubelet 配置# 检查 kubelet 服务文件是否启用轮换 sudo systemctl cat kubelet | grep rotate-certificates # ✅ 应输出--rotate-certificatestrue # 查看当前证书过期时间关键 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text | grep Not After # ✅ 输出应为Not After : Dec 12 08:22:33 2025 GMT即 1 年后 # 若未启用手动编辑 kubelet 服务配置 sudo systemctl edit kubelet # 在打开的编辑器中添加 [Service] EnvironmentKUBELET_EXTRA_ARGS--rotate-certificatestrue --cert-dir/var/lib/kubelet/pki # 保存后重载 sudo systemctl daemon-reload sudo systemctl restart kubelet提示证书轮换依赖kube-controller-manager的--cluster-signing-cert-file和--cluster-signing-key-file参数脚本已确保这两个参数指向/etc/kubernetes/pki/ca.crt和/etc/kubernetes/pki/ca.key无需额外操作。5.2 建立 etcd 定时快照备份救命后悔药etcd 是集群的唯一真相来源丢失即全盘崩溃。脚本提供backup-etcd.sh但必须手动配置 cron# 创建备份目录 sudo mkdir -p /opt/etcd-backup # 编写备份脚本/usr/local/bin/etcd-backup.sh cat EOF | sudo tee /usr/local/bin/etcd-backup.sh #!/bin/bash ETCDCTL_API3 ETCD_ENDPOINTShttps://127.0.0.1:2379 CA_CERT/etc/kubernetes/pki/etcd/ca.crt CERT/etc/kubernetes/pki/etcd/server.crt KEY/etc/kubernetes/pki/etcd/server.key BACKUP_DIR/opt/etcd-backup TIMESTAMP$(date %Y%m%d-%H%M%S) BACKUP_FILE${BACKUP_DIR}/etcd-snapshot-${TIMESTAMP}.db # 执行快照 /usr/bin/etcdctl --endpoints$ETCD_ENDPOINTS \ --cacert$CA_CERT --cert$CERT --key$KEY \ snapshot save $BACKUP_FILE # 保留最近 7 天备份 find $BACKUP_DIR -name etcd-snapshot-*.db -mtime 7 -delete EOF sudo chmod x /usr/local/bin/etcd-backup.sh # 添加每日凌晨 2 点备份的 cron (crontab -l 2/dev/null; echo 0 2 * * * /usr/local/bin/etcd-backup.sh) | crontab -参数说明etcdctl snapshot save是原子操作不会影响集群运行--cacert/--cert/--key必须指向 kubeadm 生成的 etcd 证书路径固定为/etc/kubernetes/pki/etcd/。切勿使用自签名证书否则备份失败。5.3 限制 kube-system 命名空间资源用量防 OOM Killkube-system中的coredns、calico-node等组件若无限制可能吃光节点内存触发 OOM Killer 杀死关键进程。脚本已在kube-system中注入 ResourceQuota# 创建 resource-quota.yaml cat EOF | kubectl apply -f - apiVersion: v1 kind: ResourceQuota metadata: name: kube-system-quota namespace: kube-system spec: hard: requests.cpu: 2 requests.memory: 4Gi limits.cpu: 4 limits.memory: 8Gi EOF # 验证配额已生效 kubectl get resourcequota -n kube-system # ✅ 输出应显示NAMEkube-system-quota, AGE1m, REQUESTS..., LIMITS... # 为 calico-node 设置默认 LimitRange避免单 Pod 占满 cat EOF | kubectl apply -f - apiVersion: v1 kind: LimitRange metadata: name: calico-limit namespace: kube-system spec: limits: - default: cpu: 250m memory: 512Mi defaultRequest: cpu: 100m memory: 256Mi type: Container EOF注意ResourceQuota限制整个命名空间总用量LimitRange为新创建 Pod 设置默认 limit/request。两者叠加才能防止某个组件失控。若部署后发现calico-node重启检查其日志是否含OOMKilled若是则调高LimitRange中的memory值。6. 验证集群稳定性用 3 个真实场景压测你的 K8s 集群装完不是终点跑通才是。我每次部署完必做这三件事——不是为了炫技而是因为过去踩过太多坑某次以为集群 OK结果上线业务后 DNS 解析延迟飙升另一次kubectl get nodes显示 Ready但kubectl top node报metrics-server未就绪导致 HPA 失效。下面这三招是我从模拟项目X 的 12 次线上事故中提炼出的最小可行验证集。6.1 场景一持续 10 分钟的 DNS 压力测试暴露 CoreDNS 隐患很多集群nslookup单次成功但高并发下 CoreDNS 就崩。用k8s-dns-perf工具模拟真实流量# 部署 dns-perf 工具基于 busybox kubectl run dns-perf --imagebusybox:1.35 --rm -it --restartNever -- sh -c for i in $(seq 1 600); do nslookup kubernetes.default.svc.cluster.local 2/dev/null | grep Address: | head -1 sleep 0.1 done 2/dev/null | wc -l # ✅ 正常应返回 600 行即 600 次成功解析 # ❌ 若返回远少于 600如 200说明 CoreDNS 响应超时需检查 # - kubectl top pod -n kube-system 查看 coredns 内存/CPU 使用率 # - kubectl logs -n kube-system deploy/coredns 查看是否有 timeout 日志 # - 在 coredns ConfigMap 中增加 cache 插件cache 300逻辑说明sleep 0.1模拟每秒 10 QPS600 次即 10 分钟。CoreDNS 默认无缓存高并发下频繁查询 upstream DNS 服务器极易超时。解决方案是在corednsConfigMap 中.:53块内插入cache 300将 TTL300 秒的记录缓存。6.2 场景二滚动更新 DaemonSet检验节点自愈能力DaemonSet 如calico-node、kube-proxy必须能在节点异常时自动重建。我们主动 kill 一个calico-nodePod观察是否自动恢复# 获取当前 calico-node pod 名称 CALICO_POD$(kubectl get pods -n kube-system -l k8s-appcalico-node -o jsonpath{.items[0].metadata.name}) # 删除它模拟节点宕机 kubectl delete pod -n kube-system $CALICO_POD # 等待 30 秒检查是否重建 sleep 30 NEW_CALICO_POD$(kubectl get pods -n kube-system -l k8s-appcalico-node -o jsonpath{.items[0].metadata.name}) # ✅ 若 $NEW_CALICO_POD 与 $CALICO_POD 不同且状态为 Running则通过 # ❌ 若长时间2 分钟无新 Pod或新 Pod 处于 Pending/ContainerCreating则检查 # - kubectl describe pod -n kube-system $NEW_CALICO_POD | grep Events # - 常见原因是节点磁盘满/var/lib/calico 无空间或 CNI 配置损坏/etc/cni/net.d/提示DaemonSet 的自愈依赖kube-controller-manager的--node-monitor-grace-period40s参数脚本已设为 40 秒。若describe pod显示NodeLost事件说明节点心跳超时控制器已将其标记为 NotReady 并触发重建。6.3 场景三跨命名空间 Service 访问验证 NetworkPolicy 生效性很多团队部署完 Calico 就以为网络通了却忽略了 NetworkPolicy 默认放行所有流量。我们创建一个拒绝所有入口的策略再测试是否生效# 创建测试命名空间和 nginx 服务 kubectl create ns test-ns kubectl run nginx-test --imagenginx:1.21 -n test-ns kubectl expose pod nginx-test --port80 -n test-ns # 创建默认拒绝所有入口的 NetworkPolicy cat EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: test-ns spec: podSelector: {} policyTypes: - Ingress EOF # 从 default 命名空间尝试访问应失败 kubectl run test-curl --imagecurlimages/curl -it --rm --restartNever -- \ curl -s -o /dev/null -w %{http_code} http://nginx-test.test-ns.svc.cluster.local # ✅ 正确输出应为000连接超时因 NetworkPolicy 拦截 # ❌ 若返回 200说明 NetworkPolicy 未生效检查 # - kubectl get networkpolicy -n test-ns 确认策略存在 # - kubectl get pods -n kube-system -l k8s-appcalico-node 查看 calico-node 是否 Running # - Calico 默认启用 NetworkPolicy无需额外配置但需确保 calico-node 版本 ≥ v3.20注意NetworkPolicy 是“白名单”模型default-deny-ingress仅拒绝入口出口仍放行。若想测试出口策略需创建policyTypes: [Egress]的策略并用curl google.com测试。从那以后我每次部署完 K8s都强制走一遍这三步压测——不是信不过脚本而是信不过自己漏掉的某个systemctl enable或某行sed替换。Kubernetes 的魅力在于它的确定性只要版本、参数、顺序都对它就一定按预期运行它的残酷也在于此一个cgroup driver写错整个集群就卡在NotReady。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
