它是什么:用熟悉话理解 Google Cloud
先别被名字绕晕,Google Cloud 是 GCP 上的云服务集合。常用产品包括 Compute Engine、Cloud Storage、BigQuery、GKE 与 Cloud Run:Compute Engine 约等于 EC2/Azure VM,Cloud Storage 约等于 S3/Blob,BigQuery 是查海量数据的数据仓库,GKE 约等于 EKS/AKS,Cloud Run 把容器丢上去就跑,不用自己养服务器。
对 AWS 和 Azure 用户来说,可先把项目理解成资源边界,把 IAM 理解成权限中心,把 VPC 理解成网络底座。项目的账单、配额、API 开关和资源归属都围着它走;IAM 只回答“谁能对什么资源做什么”;VPC 放子网、路由和防火墙规则。Linux 服务器常见落点是 Compute Engine 上的 VM,通过 SSH 登录,配合磁盘、快照、镜像和防火墙规则运维:磁盘像系统盘或数据盘,快照像备份点,镜像像可复制模板,防火墙规则决定谁能连进来。
想跟着做,先在控制台顶部选好项目,再打开右上角 Cloud Shell;它自带 gcloud,不用本地安装。下面先启用 Compute Engine API,再建独立 VPC、只放行自己出口 IP 的 SSH 规则,最后建 VM 并演练数据盘、快照和镜像。这样做是为了把“资源放哪、谁能进、怎么备份”一次看清。
gcloud services enable compute.googleapis.com
gcloud compute networks create demo-vpc --subnet-mode=custom
gcloud compute networks subnets create demo-subnet --network=demo-vpc --region=asia-east1 --range=10.10.0.0/24
MY_IP="$(curl -s https://ipinfo.io/ip)/32"
gcloud compute firewall-rules create allow-ssh-from-me --network=demo-vpc --allow=tcp:22 --source-ranges="$MY_IP" --target-tags=ssh-demo
gcloud compute instances create demo-vm --zone=asia-east1-b --machine-type=e2-micro --image-family=debian-12 --image-project=debian-cloud --boot-disk-size=10GB --tags=ssh-demo --subnet=demo-subnet
gcloud compute disks create demo-data --size=10GB --zone=asia-east1-b
gcloud compute instances attach-disk demo-vm --disk=demo-data --zone=asia-east1-b
gcloud compute disks snapshot demo-vm --snapshot-names=demo-boot-snapshot --zone=asia-east1-b
gcloud compute images create demo-image --source-snapshot=demo-boot-snapshot
登录时复制这一条,看到提示符变化就成功了;结束 VM 会话就能回到 Cloud Shell:
gcloud compute ssh demo-vm --zone=asia-east1-b
- 常见坑:项目没绑结算账户、API 没启用或 IAM 没权限,都会让命令失败;不是命令写错。
- 重复执行会提示资源已存在;别把 SSH 规则写成 0.0.0.0/0,Cloud Shell 出口 IP 变了要重新查。
- 数据盘附加后,还要进 Linux 格式化并挂载;快照能备份盘,但重要数据库要先停写或按应用流程做一致性备份;测试完删除 demo-* 资源,避免继续计费。
解决什么问题:降低跨平台学习成本
面向 AWS 和 Azure 用户的 Google Cloud,降低跨平台学习成本,先别背名词,先做翻译:EC2、Azure VM 对应 Compute Engine,都是选规格、镜像、开关机的虚拟服务器;S3、Blob Storage 对应 Cloud Storage,都是用“桶”存图片、日志、备份。这样对照,就不会把实例、系统盘、对象文件混成一团。
零基础打开 Console 右上角 Cloud Shell,粘贴下面只读命令。为什么先跑?它确认 CLI、登录身份、默认项目和可访问项目,不会建资源、不扣费;能避免把测试机建到生产项目,或账单挂到个人结算账号。
gcloud --version
gcloud config list
gcloud auth list
gcloud projects list --limit=5
层级要这样记:组织是公司顶层,文件夹按部门或环境分组,项目才是放虚拟机、桶、API、权限的篮子;结算账号管钱,由项目关联,不是登录账号;服务账号给程序用,不是给人登录。资源层级就是“组织 / 文件夹 / 项目 / 具体资源”,IAM 权限从上往下继承,账单看项目关联。常见坑:在组织里找“开机器”、以为文件夹自动付账、把服务账号发给同事、删项目忘了里面有资源。
团队评估按四项打勾:网络看 VPC、子网、防火墙、VPN/专线;数据看对象存储、数据库、同步、出网流量费;容器看镜像、Kubernetes、发布流程能否迁到 GKE、Artifact Registry、Cloud Build;运维看日志、监控、告警、脚本能否复用。每项标“可照搬、要改造、暂不动”:依赖少就只做试点,原厂服务绑得深或搬数据贵就混合部署,权限、账单、网络、值班都跑通后再整体迁移。
怎么上手:从控制台到第一台 VM
用过 AWS/Azure 的话,把 Google Cloud 的项目当成「资源盒子」:VM、网络、账单都归它管。先在控制台顶部项目选择器「新建项目」,记下全局唯一项目 ID;到「结算 > 账号管理」绑定结算账号;再到「结算 > 预算和提醒」设小额预算,阈值 50%/90%/100%。因为磁盘、快照、公网 IP 会一直计费,预算只提醒,不会自动停机。
再装 gcloud(macOS/Linux 一路回车用默认目录;Windows 用安装包)。gcloud init 负责浏览器登录和选项目;第二块固定项目、区域并启用 API,避免命令跑到别的项目或区域。
curl https://sdk.cloud.google.com | bash
export PATH="$HOME/google-cloud-sdk/bin:$PATH"
gcloud init
printf "输入刚创建的项目ID:"
read PROJECT_ID
gcloud config set project "$PROJECT_ID"
gcloud config set compute/region asia-east1
gcloud config set compute/zone asia-east1-b
gcloud services enable compute.googleapis.com
项目 ID 不是项目名称;区域选错,后面会找不到实例。
回控制台建网络:「VPC 网络 > 创建 VPC 网络」选自定义,建 lab-vpc、子网 lab-subnet、区域 asia-east1、网段 10.0.1.0/24;自动模式会每区生成网段,不适合练习。「VPC 网络 > 防火墙 > 创建规则」建入站规则:目标标记 lab-ssh,来源填自己公网 IP 加 /32,开 tcp:22,练网页再开 tcp:80。别用 0.0.0.0/0 放行全网 SSH,扫描器很快来撞密码;VM 也要填同样网络标记,否则规则不生效,0.0.0.0/0 是全网,/32 才是一台机器。
在「Compute Engine > 虚拟机实例 > 创建实例」建 lab-vm:区域 asia-east1-b、机型 e2-micro、Debian/Ubuntu Linux 镜像、网络选刚建的 VPC/子网并填 lab-ssh。Linux 轻、文档多、SSH 最省事。点控制台「SSH」登录,或本地复制:
mkdir -p ~/.ssh
test -f ~/.ssh/google_compute_engine || ssh-keygen -t rsa -f ~/.ssh/google_compute_engine -N "" -q
gcloud compute ssh lab-vm --zone=asia-east1-b --quiet
- 挂载盘:本地建盘并附加,再到 SSH 窗口执行第二块;mkfs、写 fstab 只做一次,nofail 可避免盘不在时 VM 起不来。
gcloud compute disks create lab-data --size=10GB --zone=asia-east1-b --type=pd-balanced gcloud compute instances attach-disk lab-vm --disk=lab-data --zone=asia-east1-b --device-name=lab-datasudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/disk/by-id/google-lab-data sudo mkdir -p /mnt/lab-data sudo mount -o discard,defaults /dev/disk/by-id/google-lab-data /mnt/lab-data UUID=$(sudo blkid -s UUID -o value /dev/disk/by-id/google-lab-data) echo "UUID=$UUID /mnt/lab-data ext4 discard,defaults,nofail 0 2" | sudo tee -a /etc/fstab df -h /mnt/lab-data - 打快照:只保一块盘某一刻,不是整机备份;系统盘要另打,快照收费且重名会失败。
gcloud compute disks snapshot lab-data --snapshot-names=lab-snap --zone=asia-east1-b --quiet - 开机脚本/日志:脚本每次启动都跑,别放耗时任务;reset 后等半分钟重新 SSH,在 VM 内看日志。
gcloud compute instances add-metadata lab-vm --zone=asia-east1-b --metadata=startup-script='#! /bin/bash echo "hello from startup script at $(date)" >> /var/log/lab-startup.log ' gcloud compute instances reset lab-vm --zone=asia-east1-b --quietsudo journalctl -u google-startup-scripts.service -n 50 --no-pager sudo tail -n 50 /var/log/lab-startup.log
与替代方案对比:AWS、Azure 和 Google Cloud
用过别的云不用重学一遍,三家干的事差不多,只是「叫法」和「特长」不同:AWS 像超大超市,产品覆盖最广;Azure 跟 Windows、Office、AD 绑得最紧,公司本来就用微软那套会很顺;Google Cloud 最常被夸的是数据分析(BigQuery)、Kubernetes(GKE)、自家骨干网,还有不绕弯子的简洁控制台。小白最先被绕晕的往往不是技术,而是同一个东西换了名字。
照着下面这张表迁移,就不容易搜错文档:
| 概念 | AWS | Azure | Google Cloud |
|---|---|---|---|
| 分类标记 | Tags 标签 | Tags 标签 | Labels 标签 |
| 资源装进一个筐 | Tag / Stack | Resource Group 资源组 | Project 项目 |
| 记账隔离最外层 | Account | Subscription 订阅 | Billing Account 下的 Project 项目 |
| 程序用的机器人身份 | IAM Role | Managed Identity | Service Account 服务账号 |
| 谁能读、谁能改 | IAM Policy | Role Assignment | IAM Policy(绑在成员上) |
容易踩的坑:Azure 的「资源组」在 Google Cloud 里没有独立对应物,新手常满控制台找它,结果白折腾。正确做法是干脆把「测试」「生产」各建成一个「项目」。不确定自己当前挂在哪,别翻菜单,直接复制这行,它会列出账号下所有项目,顺手确认命令行连没连错环境:
gcloud projects list --format="table(projectId,name,lifecycleState)"
为什么先跑它?后面建盘、开 GKE、配权限都得带 --project,选错就等于把测试机开到生产账上。另外 Google Cloud 的 IAM 是「谁 + 角色 + 绑哪一级」,在项目上给一次,下面默认继承,别挨个去写细碎策略,越写越乱。
最后算钱,千万别只比虚拟机每小时几毛。真正拉开差距的是隐形项:出公网和跨区的出口流量、机器删了还照样扣钱的磁盘、默认留存的日志、出事才想起买的支持套餐,以及为容灾做的跨区架构(多份副本、多份负载均衡、多份传输费)。把「计算 + 盘 + 流量 + 日志 + 支持 + 跨区」列成六行再乘 12 个月,拿三家计算器各填一遍,比盯着单价表靠谱得多。踩过一次「机停了账单没停」,你就懂了。
最佳实践:小白也能稳住生产环境
面向 AWS 和 Azure 用户,先把权限收紧:别把 Google Cloud 的 Owner/Editor 当默认管理员。先在控制台选定项目,打开 Cloud Shell;首次初始化用管理员账号执行下面整段,之后日常登录只用低权限账号。应用用独立服务账号,只绑写日志、写指标这类必需角色:
PROJECT_ID="$(gcloud config get-value project 2>/dev/null)"
gcloud services enable iam.googleapis.com cloudresourcemanager.googleapis.com logging.googleapis.com monitoring.googleapis.com compute.googleapis.com --project="$PROJECT_ID"
SA_ID="gcpok-ops"
SA_EMAIL="${SA_ID}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts describe "$SA_EMAIL" --project="$PROJECT_ID" >/dev/null 2>&1 ||
gcloud iam service-accounts create "$SA_ID" --display-name="Least privilege ops" --project="$PROJECT_ID"
for ROLE in roles/logging.logWriter roles/monitoring.metricWriter; do
gcloud projects add-iam-policy-binding "$PROJECT_ID"
--member="serviceAccount:${SA_EMAIL}" --role="$ROLE" >/dev/null
done
gcloud projects get-iam-policy "$PROJECT_ID" --format=json > "iam-review-$(date +%F).json"
为什么:权限越小,误删、密钥泄露、脚本跑偏的损失越小。每月把导出的 iam-review 文件复查一遍,重点看 Owner、Editor 和陌生 serviceAccount。小白坑:别给服务账号下载 JSON 密钥,别拿生产账号跑实验,删服务账号前先查谁在用它。
接着把“看得见、花得明、能恢复”打开。上面命令已启用 Cloud Logging、Cloud Monitoring 和 Compute API;再到 Monitoring 建 CPU、磁盘、健康检查告警,在 结算 > 预算和提醒 设置 50/80/100% 邮件预算告警,在 IAM 与管理 > 审核日志 打开数据读取、数据写入审计日志。VM 要开系统补丁、做磁盘快照或备份计划,并每月恢复到测试项目演练。下面命令用来盘点日志、结算账号、VM、网络、配额和审计配置:
PROJECT_ID="$(gcloud config get-value project 2>/dev/null)"
gcloud logging logs list --limit=10 --project="$PROJECT_ID"
gcloud billing accounts list --format='table(name,displayName)'
gcloud compute instances list --project="$PROJECT_ID" --format='table(name,zone,status)'
gcloud compute networks list --project="$PROJECT_ID"
gcloud compute project-info describe --project="$PROJECT_ID" --format='value(quotas)'
gcloud projects get-iam-policy "$PROJECT_ID" --format='yaml(auditConfigs)'
为什么:出事时能回答“谁改了什么、哪台机器异常、钱花到哪里、备份能不能拉起来”。小白坑:只开日志不配告警等于没人看;预算告警不会自动停机;数据读取审计日志可能增费;没演练过的备份常常就是坏备份;没结算权限就找结算管理员。
最后用基础设施即代码管理资源:把 VPC、子网、防火墙、VM、服务账号和 IAM 写成 Terraform 的 .tf 文件并提交 Git。在写好 .tf 的目录里执行:
terraform init
terraform plan -out=tfplan
terraform apply tfplan
- 为什么:代码可评审、可回滚,避免控制台点多了造成环境漂移。
- 小项目先验证:新建 sandbox 项目,先跑网络、配额和配额提升流程;用上面命令看 CPU、公网 IP、磁盘限额,再到 IAM 与管理 > 配额 提交一次提升,记录审批时间。
- 小白坑:AWS 安全组、Azure NSG 不要照搬,Google Cloud 防火墙是 VPC 级且入站默认拒绝;子网 CIDR 可能和本地或专线冲突;配额提升不是提账单额度,也不一定秒批。
- 逐步迁移:先只读和低风险服务,再无状态业务,最后数据库;每批都带监控、回滚人和回滚脚本。
常见问题(FAQ)
AWS 用户先学 Google Cloud 哪部分?
先学项目、IAM、VPC 和 Compute Engine,再对照 EC2、S3 理解计费与权限。
Azure 用户最容易混淆什么?
最容易把订阅、资源组和项目混在一起,建议先画清资源层级与账单归属。
小白要不要一开始就用 GKE?
不建议,先用一台 VM 熟悉网络、磁盘和日志,再按业务需要学习容器。
如何控制试玩成本?
设置预算告警、限额和自动关停,删除闲置磁盘、快照、公网 IP 与日志接收器。
不想自己折腾 GCP?我们提供云平台代维护、上云迁移与账单代付服务,一对一技术支持。
