GCP自动发货 GCP谷歌云ComputeEngine评测
你有没有试过，在深夜三点，对着GCP控制台点下「Create Instance」后，突然发现——它没问你要不要公网IP，而是默默给你配了个私网地址，然后你抓着鼠标在VPC设置里狂翻十分钟，才恍然大悟：哦，原来‘外部IP’那个开关，藏在‘Management, security, disks, networking, sole tenancy’这个折叠菜单的第三层子页签里，名字还叫‘External IP’，不是‘Public IP’，更不是‘Egress Access’……
欢迎来到Google Cloud Platform（GCP）Compute Engine的世界——一个把极简主义和隐性复杂度揉成一团、再撒上薄薄一层北欧冷幽默的云服务。它不像AWS那样事无巨细地列满选项，也不像阿里云那样用中文按钮亲切问候你‘立即购买’；它更像一位穿高领毛衣、说话慢条斯理但总在关键处停顿两秒的瑞士工程师，等你自己想通逻辑。
一、开箱即用？不，是开箱即查文档
创建一台VM，本该是云平台最基础的动作。GCP做到了‘快’：选区域、挑机器类型、选系统镜像、点创建——整个流程30秒内能走完。但‘快’的背面，是大量默认值在暗中投票。比如，默认不分配外部IP；默认禁用串行端口日志；默认关闭OS Login（意味着你得自己管SSH密钥）；默认磁盘加密用的是Google-managed key，而非Customer-managed——这些‘默认’不会弹窗提醒，也不会加粗标红，只在你连不上、登不进、备份失败时，默默亮起一盏小红灯。
举个真实案例：我们给客户部署一套K8s节点池，用Terraform写好模板，跑CI/CD自动拉起3台e2-standard-4。结果集群初始化卡住——kubectl get nodes始终为空。排查两小时，发现所有节点都只有内网IP，而节点上的kubelet默认往https://172.16.0.1（Master内网地址）注册，但Master根本收不到请求。真相？GCP的‘默认网络’（default VPC）虽然开了自动防火墙规则，但default-allow-internal只放行内网流量，而节点间通信居然需要额外勾选‘Allow HTTP traffic’和‘Allow HTTPS traffic’——哪怕你压根没开Web服务。这不是安全严谨，这是把网络策略当拼图游戏玩。
二、网络：VPC不是画布，是乐高说明书
GCP的VPC是全球单平面（Global VPC），听着很酷，实际意味着：你在us-central1建的子网，和asia-east1的子网，天然可互通——但前提是，你记得为两个子网分别配置路由表、防火墙规则、服务账号权限，并且确认项目级API已启用Compute API。漏一步？流量就消失在虚空里，连ICMP都不回你一句‘Destination Host Unreachable’，只留你对着ping: timeout发呆。
更迷的是‘别名IP范围’（Alias IP Ranges）。它本意是让Pod直接获得VPC内IP，绕过NAT。但当你在创建实例时勾选‘Enable Alias IPs’，GCP不会告诉你：这个功能必须搭配‘Custom Subnet Mode’使用；而一旦你选了Custom模式，就不能再用‘Auto Mode’自动生成子网——你得手动规划CIDR，计算掩码，预留未来扩容空间。我们曾因填错一个/28掩码，导致后续要加50个节点时，硬生生拆了3个子网重配。那一刻，我盯着控制台，仿佛看见Larry Page在白板上写了句：‘Networking should be simple. (Just kidding.)’
三、磁盘与镜像：快照不是备份，是时间胶囊
GCP自动发货 GCP的持久化磁盘（Persistent Disk）分标准盘（HDD）、SSD盘、平衡盘（Balanced）三种。表面看，SSD盘IOPS随容量线性增长——1TB SSD盘≈3000 IOPS。但实测发现：当磁盘忙于处理大量小文件随机读写（比如WordPress插件更新+WP-Cron高频触发），IOPS会骤降到1/3，且延迟飙到80ms以上。原因？GCP底层做了IO节流（IO Throttling），且不公开阈值。解决办法？不是升配，而是换用‘Local SSD’——但它不持久，关机即丢，只能当缓存盘用。
再说自定义镜像。你花3小时装好Java环境、调好JVM参数、打完安全补丁，打包成镜像上传——恭喜，你获得了一张‘静态快照’。但问题来了：这镜像里的/etc/hosts还写着旧实例名；systemd服务仍绑着原IP；甚至gcloud auth login残留了上一台机器的凭据。GCP官方建议用‘startup script’动态注入配置，可一旦脚本里有curl超时或apt源抽风，整台实例就卡在‘Starting’状态，连串口日志都刷不出来。我们最后的解法？写了个‘镜像净化脚本’，在打包前自动清空网络配置、重置SSH主机密钥、擦除cloud-init缓存——把它塞进CI流水线，当成镜像发布的最后一道安检。
四、GPU：挂得上，不一定跑得动
给实例挂NVIDIA T4 GPU？点几下就完事。但当你运行nvidia-smi看到GPU利用率长期为0，别急着骂驱动——先检查‘GPU quota’。GCP对每个区域的GPU配额卡得极死，且默认只给0个。申请提升？填表、等审批、邮件来回、人工审核，最快也要2工作日。更绝的是：你申请了us-west1的T4配额，却在us-central1创建实例——系统不会报错，只会静默忽略GPU请求，实例照常启动，只是‘GPU设备’根本不存在。
还有驱动版本陷阱。GCP提供预装NVIDIA驱动的镜像（如‘ubuntu-minimal-2204-lts’带470驱动），但TensorFlow 2.15要求450.80.02以上——470满足，可PyTorch 2.1又推荐515驱动。你升级？可能触发内核模块签名冲突；你不升？训练速度慢30%。我们最终方案：用‘Container-Optimized OS’ + Docker，把驱动和框架全打进镜像，彻底绕过宿主机驱动层。代价？镜像体积从2GB涨到8GB，拉取时间多47秒——但至少，每次启动都确定能‘看见GPU’。
五、账单：最温柔的刀，割在月末
GCP按秒计费，听上去很美。但‘秒’的起点不是你点‘Create’，而是实例进入‘RUNNING’状态；‘秒’的终点也不是你点‘Stop’，而是实例完全停稳并释放内存——中间可能有15~45秒‘灰色时间’，照样扣钱。更隐蔽的是‘Preemptible VM’（抢占式实例）：价格低至按需实例的1/4，但随时可能被回收。GCP不会提前通知，只在回收前30秒发一条metadata API消息。如果你的应用没做checkpoint容错，一次回收=3小时训练白干。
省钱技巧？三条铁律：
① 别信‘Always Free Tier’——它只覆盖f1-micro机型每月720小时，且仅限特定区域；
② 开启‘Committed Use Discounts’（CUD）前，先用‘Recommendations’页看预测用量，GCP的AI有时会把测试环境流量也当生产量算；
③ 把开发环境实例设为‘Auto-delete boot disk’+‘On host maintenance: Terminate’，再配个Cloud Scheduler每天23:59自动关机——我们靠这招，让测试集群月账单从$1,200压到$187。
结语：它不是不好，只是不惯着你
Compute Engine不是烂产品，相反，它稳定、可靠、API干净、跨区域扩展能力一流。它的‘难’，源于一种克制的设计哲学：拒绝保姆式引导，相信用户愿意读文档、愿意思考依赖关系、愿意为抽象能力支付学习成本。它适合那些把‘infrastructure as code’刻进DNA的团队，不适合想点几下就上线WordPress的小白店主。
所以，下次当你又在防火墙规则里迷失方向，请记住：这不是bug，是GCP在用沉默提醒你——云，终究不是水电煤，而是一门需要重新理解的语法。而真正的自由，永远诞生于看清约束之后。
