kubernetes 管理物理机

bernetes可将物理机作为工作节点（Node），通过Kubelet等组件管理其上运行的容器化应用，实现资源调度、故障恢复及自动扩缩容等功能

是关于如何使用 Kubernetes（K8S）管理物理机的详细指南，涵盖部署、配置、资源调度及监控等核心环节：

基础架构准备

安装与初始化集群
- 前置条件：确保所有物理机已更新软件包并安装依赖项（如 apt-transport-https、ca-certificates 等），通过 kubeadm 工具初始化主节点，指定网络 CIDR（--pod-network-cidr=10.244.0.0/16），并配置 API Server 的可访问 IP 地址，执行命令后会自动生成加密配置文件，需将其复制到用户目录以授权操作权限。
- 节点加入：其他物理机作为工作节点加入集群时，需运行 kubeadm join 命令，并验证网络连通性，此过程依赖于预先配置好的容器运行时环境（如 Docker）。
组件功能解析
- Etcd存储集群状态数据，支持高可用性设计；即使部分节点故障，只要主 Etcd 存活即可维持基础服务；
- Scheduler根据资源需求和节点标签进行智能调度；
- Kubelet持续监控本机容器生命周期，确保 Pod 始终处于预期状态；
- Kube-proxy实现跨节点的网络代理与负载均衡，支持多种转发模式（如 iptables、IPVS）。

节点标签策略：为物理机打上特定标签（如 node-type=physical），以便在创建 Pod 时通过 nodeSelector 字段精准指定运行位置，示例 Yaml 配置如下：
```
apiVersion: v1
kind: Pod
metadata:
name: pod-on-physical
spec:
containers:
```

name: nginx
image: nginx:latest
nodeSelector:
node-type: physical


此机制允许管理员按硬件特性（如 GPU、存储类型）分类管理资源池。

资源限额控制：借助 Node Resource Manager (NRM) 组件细化 CPU/内存分配，部署 NFD（Node Feature Discovery）以自动检测硬件能力，结合 resources.requests/limits 参数约束容器的资源消耗范围，典型配置如下：
```
resources:
requests:
cpu: "1000m"
memory: "1Gi"
limits:
cpu: "2000m"
memory: "2Gi"
```
该策略可避免因某个容器过度占用导致整台物理机性能下降。

动态监控面板：使用 K8S Dashboard 可视化界面实时查看各物理机的利用率、日志流及事件告警，同时集成 Prometheus + Grafana 栈，构建历史性能趋势分析看板。
服务暴露方案：采用 Ingress 控制器统一管理外部访问入口，替代传统的 NodePort/LoadBalancer 模式，通过域名路径规则将流量路由至不同 Service，减少端口冲突并提升安全性。
```
host: example.com
paths:
```

path: /app1
serviceName: svc-a
port: 8080


此架构支持基于七层协议的流量分发，适配复杂业务场景。

存储卷持久化：针对有状态应用，配置 HostPath 或本地存储卷直接挂载物理机目录，注意此类方案缺乏跨节点迁移能力，适用于数据库等强一致性要求的场景。

以下是相关问答FAQs：

问：如何在不重启的情况下更新物理机的内核参数？
答：可通过修改 Kubelet 的启动参数（如 --system-reserved=cpu=500m,memory=1Gi）动态调整系统预留资源，无需重启节点，但涉及内核模块变更时仍需谨慎操作。
问：能否混合部署虚拟机与物理机到同一个 K8S 集群？
答：可以，只需为不同架构的节点设置差异化标签（如 arch=amd64、accelerator=nvidia-gpu），并在调度策略中区分任务类型，但需注意网络插件兼容性及镜像镜像格式的统一

原创文章，发布者：酷盾叔，转转请注明出处：https://www.kd.cn/ask/93406.html