+86 189 8218 1436 周一至五 10:00-22:00

面向 AWS 和 Azure 用户的 Google Cloud

TL;DR:用 AWS、Azure 熟悉概念对照 Google Cloud,讲清项目、权限、网络、VM、存储与计费,并给出上手和运维避坑步骤。

它是什么:用熟悉话理解 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
  1. 挂载盘:本地建盘并附加,再到 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-data
    sudo 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
  2. 打快照:只保一块盘某一刻,不是整机备份;系统盘要另打,快照收费且重名会失败。
    gcloud compute disks snapshot lab-data --snapshot-names=lab-snap --zone=asia-east1-b --quiet
  3. 开机脚本/日志:脚本每次启动都跑,别放耗时任务;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 --quiet
    sudo 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?我们提供云平台代维护、上云迁移与账单代付服务,一对一技术支持。

查看代维服务 →

发表评论