[Kubernetes] 除了主节点(Master)和工作节点(Worker),还有’基础设施节点(Infra Node)’?🧐

大家好!今天,我将深入探讨“Infra Node(基础设施节点)”这个概念,它是在学习Kubernetes架构或实际操作中经常会听到的。

通常,初学Kubernetes时,我们只学习两种节点:控制平面(Control Plane/Master)和工作节点(Worker Node)。然而,在运维团队会议或架构设计文档中,Infra Node这个词却会不时出现。

对于那些曾困惑于“咦?我学过的书里没有这个啊?”的朋友们,我将完美地整理出基础设施节点的身份和存在理由。🚀


1. 基础设施节点(Infra Node)的身份是什么? 🤔

开门见山地说,基础设施节点是“专门用于运行集群管理核心工具的工作节点”。

普通的工作节点(Worker Node)是我们开发的业务应用程序(如Java、Python、Node.js等)运行的地方。但是,为了让Kubernetes集群正常运行,除了应用程序之外,还必须有以下系统级容器:

  • Ingress Controller: 接收并连接外部流量的守门员
  • Monitoring System: 状态监控工具,如Prometheus、Grafana
  • Logging System: 日志收集工具,如Fluentd、ELK/EFK堆栈
  • Container Registry: 镜像仓库,如Harbor、Quay

这些组件是整个集群的生命线。因此,为了不与普通应用程序混淆,它们被集中放置在“隔离的专用节点”上,并受到精心(?)管理。这个节点就是我们所说的Infra Node。


2. 它是Kubernetes的官方名称吗? 📚

这个问题的答案是“一半对,一半错”。

❌ 纯净Kubernetes (Vanilla Kubernetes)

在官方文档(Docs)或API规范中,并没有名为Infra Node的官方资源类型。官方上只存在Control Plane和Worker。也就是说,在纯净Kubernetes中,基础设施节点是一种“架构设计模式(Design Pattern)”和惯用语。

⭕ 红帽OpenShift (Red Hat OpenShift)

在企业级Kubernetes解决方案OpenShift中,它是一个官方术语。文档中明确记载,甚至在计算许可费用时,Infra Node有时还会被排除在计费对象(Subscription)之外,享受优惠。(具体取决于版本)

💡 总结:在实际工作中,无论平台类型如何,“隔离管理型Pod的节点”通常都被统称为基础设施节点。


3. 为什么要特意分离节点(优点) 🛠️

难道不能把所有东西都混在工作节点上运行吗?当然可以。但在大规模的运营环境中,强烈建议出于以下原因进行分离:

① 解决“吵闹的邻居(Noisy Neighbor)”问题 🔇

监控系统(例如:Prometheus)会占用大量内存。如果它与业务应用程序在同一个节点上,并且由于应用程序流量激增导致节点宕机,那么应用程序会崩溃,同时负责监控的系统也会随之崩溃,造成巨大灾难。分离到基础设施节点可以防止这种资源干扰。

② 安全和网络隔离 🛡️

最先接收外部用户流量的Ingress Controller(Router)在安全上是敏感的。只将基础设施节点连接到公共网络(Public Network/DMZ),并将包含实际数据的工作节点隐藏在私有网络(Private Network)深处,这样构建安全架构会容易得多。

③ 成本优化 💰

如前所述,一些商业解决方案(如OpenShift)可能会对不运行业务逻辑的基础设施节点免除许可费用。


4. 如何实现?(技术原理) ⚙️

没有哪个节点天生就被定义为“基础设施节点”!它是通过给普通工作节点附加标签(Label)和污点(Taint)后天创建的。

步骤 1. 附加标签(名牌)

# 为特定节点分配infra角色
kubectl label node worker-node-01 node-role.kubernetes.io/infra=

步骤 2. 设置污点(出入管制) 阻止普通应用程序Pod调度到此节点。

# infra节点禁止普通Pod!
kubectl taint nodes worker-node-01 node-role.kubernetes.io/infra:NoSchedule

步骤 3. Pod部署时设置(发放通行证) 在Ingress或Monitoring Pod的yaml文件中添加tolerations(通行证)和nodeSelector(指定座位),以确保它们只部署在基础设施节点上。


5. 总结 🎁

总而言之,Infra Node是一种蕴含着运维智慧的架构,旨在使Kubernetes集群运行得更稳定、更安全。

  • 小型集群: 没有必要特意分离。Master/Worker就足够了。
  • 大型/商业集群: 为了稳定性,积极考虑分离日志、监控、Ingress等的基础设施节点配置。

现在,无论在哪里听到“基础设施节点”这个词,你都可以从容不迫地表现出你的专业知识了!😎



Comments

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注