Kubernetes物理机部署:深入解析与实战指南
在云原生技术席卷全球的背景下,Kubernetes (K8s) 已成为容器编排的事实标准,虽然公有云托管K8s服务(如GKE、EKS、AKS)非常流行,物理机(裸金属)部署因其独特的优势,在特定场景下仍是关键选择,本文将深入探讨K8s物理机部署的核心概念、架构设计、实施步骤、挑战与最佳实践。
为什么选择物理机部署Kubernetes?
- 极致性能与低延迟: 绕过虚拟化层(Hypervisor),容器直接运行在物理硬件上,CPU、内存、网络I/O、磁盘I/O性能达到最优,尤其适合高性能计算(HPC)、金融交易、实时数据分析、AI/ML训练推理等场景。
- 硬件资源专属与隔离: 对安全合规性要求极高的场景(如金融、政府、军工),物理机提供绝对的硬件隔离,避免多租户环境下的潜在风险。
- 成本效益(特定规模): 对于长期运行、资源需求稳定且庞大的工作负载,直接购买和维护物理机可能比长期租用同等算力的云实例更具成本优势。
- 硬件定制化与利用: 充分利用现有物理基础设施投资,或部署特殊硬件(如GPU、FPGA、高性能NVMe SSD、特定网卡(DPDK, SR-IOV))。
- 数据主权与合规: 数据完全驻留在自有或指定数据中心的物理设备上,满足严格的数据本地化法规要求。
物理机部署 vs. 云环境部署:关键差异
特性 | 物理机部署 (裸金属) | 云托管/虚拟机部署 |
---|---|---|
基础设施层 | 直接管理物理服务器、网络、存储 | 云提供商管理底层硬件 |
资源隔离 | 物理隔离(最高级别) | 虚拟化隔离(通常足够安全) |
性能 | 最优 (无虚拟化开销) | 良好 (存在少量虚拟化开销) |
弹性伸缩 | 较慢 (需采购、上架、配置新物理机) | 极快 (API秒级创建虚拟机/节点) |
初始成本 | 较高 (CAPEX – 硬件采购) | 较低 (OPEX – 按需付费) |
运维复杂度 | 高 (需专业团队管理硬件、OS、K8s集群) | 较低 (云提供商管理底层,用户管K8s) |
高可用(节点级) | 依赖自身冗余设计 (多机架、电源、交换机) | 依赖云可用区(AZ)和实例冗余机制 |
网络灵活性 | 高 (完全自定义拓扑、BGP、Underlay) | 受限于云VPC模型和特性 |
存储灵活性 | 高 (可直接使用本地盘、SAN/NAS、SDS) | 主要使用云块存储/文件存储服务 |
适用场景 | 高性能、强隔离、合规、硬件定制、成本敏感(长期) | 敏捷开发、快速伸缩、减少运维负担 |
物理机部署Kubernetes核心架构组件
- 物理服务器 (Nodes):
- Master Nodes (控制平面): 运行
kube-apiserver
,kube-controller-manager
,kube-scheduler
,etcd
(通常3或5节点集群保证高可用),需要足够CPU、内存和稳定的网络,建议专用。 - Worker Nodes (工作节点): 运行用户容器负载 (
kubelet
,kube-proxy
,container runtime
),配置根据工作负载需求 (CPU密集型、内存密集型、GPU等)。
- Master Nodes (控制平面): 运行
- 操作系统: 通常选择轻量级、稳定、K8s兼容性好的Linux发行版:
- 推荐: Flatcar Container Linux (专为容器优化)、Ubuntu Server LTS (20.04, 22.04)、CentOS Stream / RHEL (需注意未来支持策略变化)、openSUSE Kubic。
- 关键要求: 禁用Swap、启用必要的内核模块 (如
overlay
,br_netfilter
,ip_vs
等)、配置正确的sysctl
参数、安装container runtime
(containerd 是当前首选,Docker Engine已弃用)。
- 容器运行时 (Container Runtime): containerd 是当前K8s默认且推荐的选择,轻量高效,CRI-O 也是一个符合CRI标准的优秀替代品。
- 网络插件 (CNI – Container Network Interface): 物理机环境选择至关重要:
- Overlay网络: Calico (IPIP或VxLAN模式)、Flannel (VxLAN)、Weave Net,在现有物理网络之上构建虚拟网络,灵活性高,但有一定性能开销。
- Underlay网络:
- BGP路由型: Calico (BGP模式 – 需物理交换机支持BGP)、Kube-router,Pod IP直接在物理网络可达,性能最优,网络策略控制强。
- L2网络: MetalLB (Layer2模式 – ARP/NDP),提供LoadBalancer类型的服务外部访问,简单易用。
- SR-IOV / Device Plugin: 提供接近物理网卡性能的网络给特定Pod (高性能需求)。
- 多网卡管理:
Multus CNI
允许Pod附加多个网络接口,满足复杂网络需求。
- 存储方案 (CSI – Container Storage Interface):
- 本地存储 (Local Persistent Volumes): 利用工作节点上的高性能SSD/NVMe盘,为有状态应用提供低延迟存储,需仔细规划调度 (使用
volumeBindingMode: WaitForFirstConsumer
) 和磁盘管理 (如local-static-provisioner
)。 - 外部共享存储:
- 传统SAN/NAS: 通过CSI驱动 (如 NetApp Trident, Dell EMC PowerScale/Isilon, Pure Storage) 集成。
- 分布式存储 (SDS): 在物理机集群上自建 Ceph (RBD/CephFS)、Longhorn、Rook、OpenEBS、StorageOS 等,提供高可用、可扩展的块/文件存储服务,是物理机K8s存储的主流选择。
- 本地存储 (Local Persistent Volumes): 利用工作节点上的高性能SSD/NVMe盘,为有状态应用提供低延迟存储,需仔细规划调度 (使用
- 负载均衡 (Service Exposure):
- NodePort: 最基本方式,通过节点IP+端口访问服务。
- MetalLB: 物理机必备! 为
LoadBalancer
类型的服务分配真实可路由的IP地址 (BGP模式或Layer2 ARP/NDP模式)。 - 硬件负载均衡器集成: 如 F5 BIG-IP (通过CCCL或AS3)、Citrix ADC CPX/VPX 等,通过其K8s Controller/Provider提供企业级LB功能。
- 引导与部署工具:
- kubeadm: K8s官方工具,灵活、模块化,适合自定义需求高的场景,需自行配置OS、容器运行时、网络等。
- Kubespray: 基于Ansible,功能强大,支持多节点、高可用部署,集成常用组件 (CNI, CSI, Ingress等),社区活跃。
- Rancher RKE/RKE2: Rancher Labs出品,RKE (Docker) 成熟稳定;RKE2 (原名RKE Government) 使用containerd,符合FIPS安全标准,更轻量安全。
- k0s: Mirantis推出的单二进制K8s发行版,零依赖,极简,易于嵌入和自动化。
- OpenShift (Upi): Red Hat企业级K8s平台,提供裸金属安装模式 (UPI – User Provisioned Infrastructure),功能最全但最复杂。
物理机部署Kubernetes关键步骤
-
基础设施准备:
- 硬件: 采购/准备服务器 (CPU, 内存, 磁盘 – 建议系统盘SSD,数据盘按需)、网络交换机 (支持所需VLAN、MTU、BGP等)、电源/UPS、机柜。
- 网络规划: IP地址段 (管理网络、Pod网络、Service网络、外部Ingress/LB网络)、VLAN划分、路由策略 (BGP)、防火墙规则 (放行K8s组件端口如6443, 2379-2380, 10250, 10257, 10259等)。
- 带外管理 (IPMI/iDRAC/iLO): 配置好,用于远程电源控制、监控、安装OS。
- PXE/TFTP/HTTP引导服务: 用于自动化安装操作系统 (可选但推荐)。
-
操作系统安装与配置:
- 使用自动化工具 (如Foreman, MAAS) 或手动安装选定Linux发行版。
- 配置主机名、静态IP (或DHCP保留)、DNS解析、NTP时间同步。
- 安装基础工具 (
curl
,wget
,vim
,tmux
等)。 - 内核优化: 启用模块 (
overlay
,br_netfilter
,nf_conntrack
),配置sysctl
(如net.bridge.bridge-nf-call-iptables=1
,net.ipv4.ip_forward=1
, 调整net.netfilter.nf_conntrack_max
等)。 - 禁用Swap:
swapoff -a
并注释掉/etc/fstab
中的swap行。 - 安装容器运行时: 安装并配置
containerd
(或CRI-O
)。
-
安装Kubernetes控制平面 (Master):
-
选择部署工具 (如
kubeadm
,Kubespray
,RKE2
)。 -
使用 kubeadm 示例 (高可用需额外步骤如外部etcd/LB):
# 所有节点:安装 kubeadm, kubelet, kubectl sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update && sudo apt-get install -y kubelet kubeadm kubectl && sudo apt-mark hold kubelet kubeadm kubectl # 首个Master节点初始化 (替换占位符) sudo kubeadm init --control-plane-endpoint="LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --pod-network-cidr=10.244.0.0/16 --upload-certs --apiserver-advertise-address=MASTER_NODE_IP # 按提示配置kubectl mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config # 安装Pod网络插件 (例如Calico - 注意CIDR匹配) kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml # 加入其他Master节点 (使用kubeadm join命令,带token和discovery-token-ca-cert-hash, 以及--control-plane --certificate-key)
-
-
加入工作节点 (Worker):
- 在工作节点上执行
kubeadm join
命令 (从Master初始化输出或kubeadm token create
生成)。
- 在工作节点上执行
-
部署核心网络插件 (CNI):
- 根据选择的CNI (如Calico, Cilium, Flannel),应用其对应的YAML清单,确保Pod网络CIDR (
--pod-network-cidr
) 配置一致。
- 根据选择的CNI (如Calico, Cilium, Flannel),应用其对应的YAML清单,确保Pod网络CIDR (
-
部署存储解决方案 (CSI):
- 本地存储: 部署
local-volume-provisioner
或使用Local PersistentVolume
手动管理。 - 分布式存储: 部署选定的SDS方案 (如Rook/Ceph, Longhorn),通常涉及Operator和Cluster的CRD部署。
- 本地存储: 部署
-
部署负载均衡器 (MetalLB):
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml # 创建IP地址池 (Layer2示例) cat <<EOF | kubectl apply -f - apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 192.168.1.100-192.168.1.200 # 替换为你的可用IP段 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2adv namespace: metallb-system spec: ipAddressPools: - first-pool EOF
-
部署Ingress Controller: 如Nginx Ingress Controller, Traefik, HAProxy Ingress。
-
部署监控与日志:
- 监控: Prometheus + Grafana (通常通过kube-prometheus-stack Helm Chart部署)。
- 日志: EFK Stack (Elasticsearch, Fluentd/Fluent Bit, Kibana) 或 Loki + Promtail + Grafana。
-
配置认证与授权 (RBAC): 根据安全需求配置ServiceAccount, Role, RoleBinding, ClusterRole, ClusterRoleBinding,集成LDAP/AD (如使用Dex, Keycloak)。
-
备份与灾难恢复: 使用
etcdctl
备份etcd数据,或使用Velero备份集群状态和持久卷。
物理机部署的独特挑战与最佳实践
- 挑战:
- 运维复杂度高: 硬件故障、固件/驱动更新、操作系统补丁、机房维护等都需要专业团队。
- 弹性伸缩慢: 新增节点涉及物理采购、上架、布线、安装配置,无法秒级响应。
- 高可用设计复杂: 需自行设计物理层冗余 (多机架、多交换机、多电源)、控制平面高可用、存储高可用。
- 硬件资源碎片化: 物理机规格可能不统一,影响K8s调度效率和资源利用率。
- 网络配置复杂: Underlay网络需要与物理网络团队紧密协作。
- 存储性能瓶颈: 本地存储单点故障,共享存储网络延迟可能成为瓶颈。
- 最佳实践:
- 基础设施即代码 (IaC): 使用Terraform、Ansible、Puppet、Chef自动化服务器配置、OS安装、基础软件安装。
- 节点标准化: 尽量统一硬件配置 (特别是Worker节点),简化管理和调度。
- 集群设计:
- 分离控制平面与工作节点: Master节点专用,不运行用户Pod。
- 多Master高可用: 至少3个Master节点,etcd集群奇数节点。
- 考虑机架/故障域: 使用
topology.kubernetes.io/zone
或自定义标签,将节点分散在不同机架/交换机下,利用Pod反亲和性 (podAntiAffinity
) 提高应用容错能力。
- 网络选择:
- 性能优先: 首选BGP Underlay (Calico BGP, Kube-router) 或高性能Overlay (Cilium eBPF)。
- 简单易用: Calico IPIP/VxLAN + MetalLB Layer2 是常见组合。
- MTU一致性: 确保物理网络、CNI、容器网络MTU设置一致 (通常9000 for Jumbo Frames优化性能)。
- 存储策略:
- 关键有状态应用: 使用高可用分布式存储 (Ceph, Longhorn) 提供持久卷。
- 高性能/临时数据: 使用
Local PersistentVolume
或emptyDir
(注意数据持久性)。 - 备份至关重要: 定期备份etcd和持久卷数据,测试恢复流程。
- 资源管理与调度:
- 设置Requests/Limits: 为所有Pod配置合理的资源请求和限制。
- 利用污点和容忍度: 为特殊硬件节点 (如GPU) 打上污点 (
taint
),只有声明了相应容忍度 (toleration
) 的Pod才能调度上去。 - 设备插件: 使用
k8s-device-plugin
暴露和管理GPU、FPGA、SR-IOV VF等特殊硬件资源。
- 安全加固:
- 主机安全: 最小化安装OS,定期更新内核和软件包,配置防火墙 (仅开放必要端口),使用SSH密钥登录。
- K8s安全: 启用Pod安全准入 (PSA/PSP替代方案),使用网络策略 (
NetworkPolicy
– Calico/Cilium提供强大实现),启用API Server审计日志,RBAC最小权限原则,定期轮换证书。 - 镜像安全: 使用私有镜像仓库,扫描镜像漏洞。
- 全面监控与告警: 监控节点硬件状态 (IPMI传感器)、操作系统指标 (CPU, 内存, 磁盘, 网络)、K8s核心组件状态 (API Server, S
原创文章,发布者:酷盾叔,转转请注明出处:https://www.kd.cn/ask/32470.html