选型

两大云托管 K8s 摆一起：差在哪，小公司怎么选 上一篇《Java 开发工程师的 K8s 职责清单》里用一小节对比了 AWS EKS 和阿里云 ACK，写的时候发现这个题目值得单独成篇——两家都在做"托管"，但计费模型、产品线布局、生态绑定的差异直接决定学习成本和选型结果，尤其对预算敏感的中小企业。 这篇把两家云托管 K8s 摊开对比：先看产品线布局，再看计费模型（最影响选型的部分），然后是全维度差异表，最后给中小企业三档推荐配置。文末记录了本次调研的时间与文档版本，方便读者核对时效。 ⚠️ 声明：本文所有对比数据来自对两家官方文档的实际检索（检索时间见文末附录），不依赖二手资料。价格可能随时调整，实际以云厂商账单为准。 1. 产品线布局：两家各摆了几个形态 先说总览。两家都从"标准托管集群"出发，各自长出了一整条产品线： %% EKS 与 ACK 产品线对照 flowchart LR EKS["AWS EKS 家族"] ACK["阿里云 ACK 家族"] E1["标准 EKS\n控制面托管 + 自管/托管节点"] E2["EKS Auto Mode\n控制面+关键组件全托管"] E3["EKS Fargate\n无服务器, 按 Pod 计费"] E4["EKS Anywhere / Distro\n私有云/自建发行版"] A1["ACK 托管集群\nPro 版 / 基础版"] A2["ACK Auto Mode\n控制面+关键组件全托管"] A3["ACK Serverless (ASK)\nECI 弹性容器实例"] A4["ACK 专有集群\n已停止新建"] A5["ACK One / 边缘版\n多云统一 / 边缘节点"] EKS --> E1 EKS --> E2 EKS --> E3 EKS --> E4 ACK --> A1 ACK --> A2 ACK --> A3 ACK --> A4 ACK --> A5 style EKS fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#ffffff,font-weight:bold style ACK fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#ffffff,font-weight:bold style E1 fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#ffffff style E2 fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#ffffff style E3 fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#ffffff style A1 fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#ffffff style A2 fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#ffffff style A3 fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#ffffff style E4 fill:#052e16,stroke:#16a34a,stroke-width:2px,color:#ffffff,font-weight:bold style A4 fill:#052e16,stroke:#16a34a,stroke-width:2px,color:#ffffff,font-weight:bold style A5 fill:#052e16,stroke:#16a34a,stroke-width:2px,color:#ffffff,font-weight:bold 几个值得注意的点： ...

三条路看监控：隧道、堡垒机，还是数据上云？ 在之前的文章里，我们为了"看一眼监控面板"折腾过不少事：部署在内网的 Prometheus/Grafana 不能直接访问，要开 SSH 隧道；隧道会断，断了要重连；连上之后还有账号密码、端口、地址一堆细节。这些"问题太多"的感慨，根源其实是同一个问题——监控系统放在私有网络里，人在外面，怎么合法地看到它？ 围绕这个问题，行业给出了三种主流答案，恰好代表三种完全不同的网络哲学： SSH 隧道（人带着加密通道进内网看数据） 堡垒机（把入口收敛到一台"守门员"，人过安检后进内网） 云原生监控（数据送出来给人看，人根本不用进内网） 这篇把三种方案的原理讲透，再放到同一张对比表里，最后给一张决策地图。它们没有优劣，只有"你愿意把哪一边放到公网上"的选择。 1. 方案 A：SSH 隧道 + 自建内网监控 原理 监控组件（Prometheus/Grafana）部署在内网，监听地址是内网 IP，公网完全摸不到。运维人员通过 SSH 端口转发（本地转发 -L 或反向转发 -R ）把内网端口"搬"到自己笔记本的 localhost 上，浏览器访问 localhost:32090 时，流量顺着 SSH 加密通道流到内网。 这套方案的核心组件： 中转机：一台有公网 IP 的机器作为唯一入口，只开 SSH； 反向隧道：内网服务器主动用 autossh （自动重连的 SSH）连到中转机，建立常驻加密通道——这样即使内网没有公网 IP、人在任何网络，通道都在； 本地转发：运维人员笔记本再 ssh -L 把通道接回 localhost。 %% 方案A: SSH 隧道 + 自建内网监控(本系列学习环境的真实形态) flowchart TD LAP["运维人员笔记本\n浏览器访问 localhost:32090"] ECS["中转机（公网 IP）\n唯一公网入口\n只开放 SSH"] DEB["内网服务器\n无公网 IP"] MON["Prometheus / Grafana\n仅监听内网地址"] AUT["autossh 反向隧道\n常驻 + 自动重连"] LAP -->|"SSH -L 本地转发\n(端口搬到 localhost)"| ECS ECS -->|"加密隧道字节流"| AUT AUT -->|"经 SSH 通道"| DEB DEB --> MON LAP -.->|"浏览器流量实际路径"| MON style LAP fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#ffffff,font-weight:bold style ECS fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#ffffff,font-weight:bold style DEB fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#ffffff,font-weight:bold style AUT fill:#052e16,stroke:#16a34a,stroke-width:2px,color:#ffffff,font-weight:bold style MON fill:#052e16,stroke:#16a34a,stroke-width:2px,color:#ffffff,font-weight:bold 特性 数据全程在内网：指标、日志不出内网，只有加密隧道里流动的"查看请求"； 暴露面最小化：公网只有中转机一个 SSH 端口，内网零暴露； 零新增组件：复用系统自带的 SSH，不需要额外部署任何产品； 认证模型：SSH 密钥对，个人密钥直连。 真实的坑（来自本系列实践） 隧道是这条链路上最脆弱的环节。SSH 双重跳转（笔记本 → 中转机 → 内网）空闲一段时间后，中转机侧可能重置连接，症状是 Read from remote host: Connection reset by peer ，浏览器打开看板立刻 HTTP 000 。解法是 autossh 保活 + 心跳参数，但自动重连只解决内网侧的反向隧道，笔记本侧的本地转发断了还是得手动拉起——这就是"单点"的代价。 ...