基于 Skaffold 的 Online Boutique 本地开发指南microservices-demo 的构建、部署与调试实战【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo本文围绕 Online Boutiquemicroservices-demo的官方开发指南展开完整讲解如何借助skaffold命令行工具在本地构建并运行这套由 10 余个微服务组成的云原生示例应用既包含面向 Google Cloud 的 GKE 集群部署路径Option 1也覆盖 Minikube / Docker for Desktop / Kind 的本地集群方案Option 2。读完本文你将掌握skaffold run、skaffold dev、skaffold delete的完整使用方式理解仓库中skaffold.yaml的构建清单与配置画像profile结构并能够在本地完成验证、端口转发与资源清理。Online Boutique 微服务架构图一、开发指南定位与前置条件Online Boutique 是一个典型的“云优先”cloud-first微服务演示应用前端提供 Web 商城页面cartservice、productcatalogservice、checkoutservice、paymentservice、shippingservice、emailservice、currencyservice、recommendationservice、adservice等后端服务之间通过 gRPC 通信协议定义见 protos/demo.proto每个服务使用不同的语言实现Go、C#、Node.js、Python、Java并各自带有独立的Dockerfile。开发指南docs/development-guide.md的目的正是解决“如何在本机把这些服务统一构建起来并部署到 Kubernetes”这一核心问题——答案是使用 Skaffold 批量完成镜像构建与部署。在开始之前需要准备以下工具与环境Docker for Desktop本地容器运行时也是 Option 2本地集群的可选实现方式之一kubectlKubernetes 命令行客户端用于与集群交互如果走 GKE 路线也可以通过gcloud components install kubectl安装skaffold 2.0.2官方建议安装最新版本。Skaffold 是本次开发流程的核心工具负责“批量构建 Docker 镜像并部署到集群”这一整套流水线克隆仓库git clone https://github.com/GoogleCloudPlatform/microservices-demo cd microservices-demo/若选择 Option 1GKE还需要一个已启用 Google Container RegistryGCR/ Artifact RegistryAR的 Google Cloud 项目若选择 Option 2本地集群可选的集群工具包括Minikube与Kind。二、Option 1部署到 Google Kubernetes EngineGKE如果你的目标是在接近生产环境的真实集群上运行这套应用推荐使用 GKE。此路径适合已经使用 Google Cloud 的开发者整个流程分为四步。1. 创建 GKE 集群并让 kubectl 指向集群首先启用 Kubernetes Engine API随后使用gcloud创建一个 Autopilot 集群这里以demo命名、区域us-central1为例并确认kubectl已连接到该集群gcloud services enable container.googleapis.comgcloud container clusters create-auto demo --regionus-central1kubectl get nodes若你的集群启用了 Workload Identity请额外参考 Google Cloud 官方关于启用 Workload Identity 的说明确保后续部署与凭据获取正常。2. 启用 Artifact Registry 并配置 Docker 认证Skaffold 构建出的镜像需要推送到镜像仓库本仓库默认使用 Artifact RegistryAR。依次执行gcloud services enable artifactregistry.googleapis.comgcloud artifacts repositories create microservices-demo \ --repository-formatdocker \ --locationus \gcloud auth configure-docker -qgcloud auth configure-docker会在本地配置 Docker CLI 对 AR 的认证使后续docker push能够成功。3. 使用 Skaffold 一键构建、推送并部署在仓库根目录执行将PROJECT_ID替换为你的 Google Cloud 项目 IDskaffold run --default-repous-docker.pkg.dev/PROJECT_ID/microservices-demo这条命令会依次完成三件事构建容器镜像依据 skaffold.yaml 中build.artifacts列出的全部服务逐一执行docker build推送镜像到 Artifact Registry镜像标签基于--default-repo参数指定的仓库地址生成应用 Kubernetes 清单执行kubectl apply部署./kubernetes-manifests目录下的全部 YAML通过 Kustomize 组织详见下文。故障排查如果在 Google Cloud Shell 中遇到 “No space left on device”磁盘空间不足错误可以改为把镜像构建放到云端——先启用 Cloud Build API再执行skaffold run -p gcb --default-repous-docker.pkg.dev/[PROJECT_ID]/microservices-demo-p gcb会激活 skaffold.yaml 中名为gcb的 profile将构建后端切换到googleCloudBuild从而绕开本地磁盘限制该 profile 使用 300 GB 磁盘、N1_HIGHCPU_32机器类型、超时 4000 秒详见skaffold.yaml第 6975 行。4. 获取外部 IP 并访问前端部署完成后通过以下命令找到前端负载均衡器的外部地址kubectl get service frontend-external然后在浏览器中访问http://EXTERNAL-IP即可看到 Online Boutique 商城页面。frontend.yaml 中定义了frontend-external这个LoadBalancer类型的 Service将 80 端口映射到 frontend 容器的 8080 端口。三、Option 2本地集群部署如果你没有 Google Cloud 环境或者希望离线开发调试可以使用本地 Kubernetes 集群。开发指南提供了三种经过验证的本地集群方案任选其一即可。方案 AMinikubeUbuntu Linux 下测试通过Minikube 是轻量级单节点集群。为确保整套微服务尤其是资源占用较高的服务能正常运行本地集群至少需要4 核 CPU4.0 GiB 内存32 GB 磁盘空间启动命令minikube start --cpus4 --memory 4096 --disk-size 32g方案 BDocker for DesktopMac / Windows 下测试通过在 Docker Desktop 的Preferences设置中勾选“Enable Kubernetes”启用内置的 Kubernetes 集群将CPUs设置为至少3Memory设置为至少6.0 GiB在Disk选项卡中磁盘空间设置为至少32 GB。方案 CKindKind 在 Docker 容器中运行 Kubernetes 控制面创建方式最简单kind create cluster本地集群的通用部署步骤无论选择哪种本地集群接下来的步骤完全一致运行kubectl get nodes确认kubectl已连接到对应集群的控制面在仓库根目录执行skaffold run注意首次运行会比较慢可能耗时约 20 分钟需要拉取基础镜像、编译各语言服务并构建镜像。如果希望在重构代码时自动重建镜像并热更新部署改用skaffold devskaffold dev会监听源码变化一旦检测到文件改动便自动触发构建与重新部署非常适合本地迭代开发运行kubectl get pods确认所有 Pod 处于Running状态由于本地集群通常没有外部负载均衡器使用端口转发访问前端kubectl port-forward deployment/frontend 8080:8080浏览器访问localhost:8080即可看到前端页面。Online Boutique 前端商城页面部署成功后的运行效果四、深入理解 skaffold.yaml构建清单与配置画像要熟练使用上述命令理解仓库根目录的 skaffold.yaml 是关键。该文件声明了 Skaffold 的完整构建与部署行为分为两个Config段。主配置app构建全部核心服务apiVersion: skaffold/v3 kind: Config metadata: name: app build: platforms: [linux/amd64, linux/arm64] artifacts: - image: emailservice context: src/emailservice - image: productcatalogservice context: src/productcatalogservice ... - image: cartservice context: src/cartservice/src docker: dockerfile: Dockerfile - image: frontend context: src/frontend - image: adservice context: src/adservice tagPolicy: gitCommit: {} local: useDockerCLI: true useBuildkit: true manifests: kustomize: paths: - kubernetes-manifests deploy: kubectl: {}要点解读build.artifacts以“镜像名 构建上下文”的形式列出全部服务。注意cartservice的上下文是src/cartservice/src其Dockerfile位于该子目录即 src/cartservice/src/Dockerfile而其他服务的Dockerfile通常直接位于各自目录根例如 src/frontend/DockerfiletagPolicy.gitCommit镜像标签基于 Git commit 生成保证每次构建的可追溯性local.useDockerCLI/useBuildkit使用本地 Docker CLI 与 BuildKit 进行构建充分利用本机缓存manifests.kustomize.paths部署清单通过 Kustomize 组织指向 kubernetes-manifests 目录——该目录下的 kustomization.yaml 汇总了全部服务的 YAML 资源loadgenerator被注释掉因为开发期间它由独立的 Skaffold 模块单独管理见下文deploy.kubectl最终通过kubectl apply完成部署。独立配置loadgenerator负载生成器第二个Configmetadata.name: loadgenerator通过requires依赖主配置仅构建loadgenerator这一个镜像上下文 src/loadgenerator并直接使用原生 YAML 清单 kubernetes-manifests/loadgenerator.yaml 部署。这样在本地开发时可以单独控制是否注入模拟用户流量。内置 profileskaffold.yaml 定义了三个 profile可按需组合激活Profile激活方式作用gcbskaffold run -p gcb将构建后端切换到 Google Cloud Build无需本地 Docker适合 Google Cloud Shell 等磁盘受限环境缺点是 GCB 不缓存构建每次从零开始耗时较长debugskaffold debug自动激活将cartservice的Dockerfile替换为Dockerfile.debug开启可调试构建network-policiesskaffold run -p network-policies在 Kustomize 路径中追加 kustomize/components/network-policies 组件为服务应用网络策略其中debugprofile 体现了 Skaffold 与源码的深度集成src/frontend/Dockerfile中通过ARG SKAFFOLD_GO_GCFLAGS接收 Skaffold 传入的调试编译参数并设置GOTRACEBACKsingle方便定位问题。五、验证部署从 Pod 状态到端口转发无论使用哪种部署路径验证环节都一致kubectl get pods正常情况下你会看到adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、loadgenerator、paymentservice、productcatalogservice、recommendationservice、shippingservice以及 Redisredis-cart等 Pod 全部处于Running状态。在 GKE 上直接通过frontend-external的负载均衡 IP 访问在本地集群中则用kubectl port-forward deployment/frontend 8080:8080将 frontend Deployment 的 8080 端口转发到本机随后访问localhost:8080。frontend 的容器端口与健康检查细节可参考 kubernetes-manifests/frontend.yaml它以/_healthz作为就绪探针与存活探针路径并注入了PRODUCT_CATALOG_SERVICE_ADDR、CURRENCY_SERVICE_ADDR、CART_SERVICE_ADDR等服务发现环境变量用于在集群内定位各 gRPC 后端服务地址如productcatalogservice:3550、checkoutservice:5050。六、扩展如何添加一个新的微服务开发指南指出Online Boutique 的核心微服务集合已经比较完整、未来不太可能频繁变动但你可能希望添加一个可选的辅助微服务来补充功能。完整的分步指引见 docs/adding-new-microservice.md其核心流程包括在 src/ 目录下为服务创建新目录命名即服务名按照既有微服务的约定放置源码例如 Python 服务至少需要README.md、入口main.py、依赖清单requirements.in与Dockerfile编写Dockerfile可参考 src/frontend/Dockerfile 的多阶段构建与安全基线写法在 kustomize/components/ 下新增组件目录写入该服务的Deployment与Service清单并保证镜像名与构建配置一致——kustomize/components/shopping-assistant/ 是一个现成的完整参考示例它同时通过 patch 为frontend注入ENABLE_ASSISTANTtrue环境变量来启用新服务将新组件加入根级 kustomize/kustomization.yaml 的components列表在根级 skaffold.yaml 的build.artifacts中登记新服务确保镜像能被批量构建更新 helm-chart 的模板与默认 valueschart 版本信息见 helm-chart/Chart.yaml最后更新 README.md、docs/img 下的架构图或新增独立文档。这套流程体现了“仓库即配置中心”的设计skaffold.yaml负责构建编排kustomize负责清单组合Helm chart 提供可打包的发布形态三者通过一致的镜像命名与服务名相互衔接。七、清理部署当你完成开发或演示后如果应用是通过skaffold run部署的可以一键清理全部已部署资源skaffold delete该命令会依据skaffold.yaml中的部署配置删除之前skaffold run应用到集群的所有 Kubernetes 资源包括 Deployment、Service 等是本地反复迭代时的常用收尾操作。对于 GKE 路径还可以在确认清理后删除整个集群以停止计费。小结本文完整复现了 docs/development-guide.md 的两条部署路径并进一步剖析了 skaffold.yaml 的构建清单、profile 机制以及 src/frontend/Dockerfile 等源码层面的集成细节。核心要点可以概括为GKE 上用skaffold run --default-repo...一键上云本地用skaffold run/skaffold dev快速迭代skaffold delete完成清理。掌握这套流程后你既能基于 Online Boutique 快速搭建可复现的演示环境也能借助skaffold dev的自动重建能力高效地进行多语言微服务的本地开发与调试。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 Skaffold 的 Online Boutique 本地开发指南：microservices-demo 的构建、部署与调试实战
基于 Skaffold 的 Online Boutique 本地开发指南microservices-demo 的构建、部署与调试实战【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo本文围绕 Online Boutiquemicroservices-demo的官方开发指南展开完整讲解如何借助skaffold命令行工具在本地构建并运行这套由 10 余个微服务组成的云原生示例应用既包含面向 Google Cloud 的 GKE 集群部署路径Option 1也覆盖 Minikube / Docker for Desktop / Kind 的本地集群方案Option 2。读完本文你将掌握skaffold run、skaffold dev、skaffold delete的完整使用方式理解仓库中skaffold.yaml的构建清单与配置画像profile结构并能够在本地完成验证、端口转发与资源清理。Online Boutique 微服务架构图一、开发指南定位与前置条件Online Boutique 是一个典型的“云优先”cloud-first微服务演示应用前端提供 Web 商城页面cartservice、productcatalogservice、checkoutservice、paymentservice、shippingservice、emailservice、currencyservice、recommendationservice、adservice等后端服务之间通过 gRPC 通信协议定义见 protos/demo.proto每个服务使用不同的语言实现Go、C#、Node.js、Python、Java并各自带有独立的Dockerfile。开发指南docs/development-guide.md的目的正是解决“如何在本机把这些服务统一构建起来并部署到 Kubernetes”这一核心问题——答案是使用 Skaffold 批量完成镜像构建与部署。在开始之前需要准备以下工具与环境Docker for Desktop本地容器运行时也是 Option 2本地集群的可选实现方式之一kubectlKubernetes 命令行客户端用于与集群交互如果走 GKE 路线也可以通过gcloud components install kubectl安装skaffold 2.0.2官方建议安装最新版本。Skaffold 是本次开发流程的核心工具负责“批量构建 Docker 镜像并部署到集群”这一整套流水线克隆仓库git clone https://github.com/GoogleCloudPlatform/microservices-demo cd microservices-demo/若选择 Option 1GKE还需要一个已启用 Google Container RegistryGCR/ Artifact RegistryAR的 Google Cloud 项目若选择 Option 2本地集群可选的集群工具包括Minikube与Kind。二、Option 1部署到 Google Kubernetes EngineGKE如果你的目标是在接近生产环境的真实集群上运行这套应用推荐使用 GKE。此路径适合已经使用 Google Cloud 的开发者整个流程分为四步。1. 创建 GKE 集群并让 kubectl 指向集群首先启用 Kubernetes Engine API随后使用gcloud创建一个 Autopilot 集群这里以demo命名、区域us-central1为例并确认kubectl已连接到该集群gcloud services enable container.googleapis.comgcloud container clusters create-auto demo --regionus-central1kubectl get nodes若你的集群启用了 Workload Identity请额外参考 Google Cloud 官方关于启用 Workload Identity 的说明确保后续部署与凭据获取正常。2. 启用 Artifact Registry 并配置 Docker 认证Skaffold 构建出的镜像需要推送到镜像仓库本仓库默认使用 Artifact RegistryAR。依次执行gcloud services enable artifactregistry.googleapis.comgcloud artifacts repositories create microservices-demo \ --repository-formatdocker \ --locationus \gcloud auth configure-docker -qgcloud auth configure-docker会在本地配置 Docker CLI 对 AR 的认证使后续docker push能够成功。3. 使用 Skaffold 一键构建、推送并部署在仓库根目录执行将PROJECT_ID替换为你的 Google Cloud 项目 IDskaffold run --default-repous-docker.pkg.dev/PROJECT_ID/microservices-demo这条命令会依次完成三件事构建容器镜像依据 skaffold.yaml 中build.artifacts列出的全部服务逐一执行docker build推送镜像到 Artifact Registry镜像标签基于--default-repo参数指定的仓库地址生成应用 Kubernetes 清单执行kubectl apply部署./kubernetes-manifests目录下的全部 YAML通过 Kustomize 组织详见下文。故障排查如果在 Google Cloud Shell 中遇到 “No space left on device”磁盘空间不足错误可以改为把镜像构建放到云端——先启用 Cloud Build API再执行skaffold run -p gcb --default-repous-docker.pkg.dev/[PROJECT_ID]/microservices-demo-p gcb会激活 skaffold.yaml 中名为gcb的 profile将构建后端切换到googleCloudBuild从而绕开本地磁盘限制该 profile 使用 300 GB 磁盘、N1_HIGHCPU_32机器类型、超时 4000 秒详见skaffold.yaml第 6975 行。4. 获取外部 IP 并访问前端部署完成后通过以下命令找到前端负载均衡器的外部地址kubectl get service frontend-external然后在浏览器中访问http://EXTERNAL-IP即可看到 Online Boutique 商城页面。frontend.yaml 中定义了frontend-external这个LoadBalancer类型的 Service将 80 端口映射到 frontend 容器的 8080 端口。三、Option 2本地集群部署如果你没有 Google Cloud 环境或者希望离线开发调试可以使用本地 Kubernetes 集群。开发指南提供了三种经过验证的本地集群方案任选其一即可。方案 AMinikubeUbuntu Linux 下测试通过Minikube 是轻量级单节点集群。为确保整套微服务尤其是资源占用较高的服务能正常运行本地集群至少需要4 核 CPU4.0 GiB 内存32 GB 磁盘空间启动命令minikube start --cpus4 --memory 4096 --disk-size 32g方案 BDocker for DesktopMac / Windows 下测试通过在 Docker Desktop 的Preferences设置中勾选“Enable Kubernetes”启用内置的 Kubernetes 集群将CPUs设置为至少3Memory设置为至少6.0 GiB在Disk选项卡中磁盘空间设置为至少32 GB。方案 CKindKind 在 Docker 容器中运行 Kubernetes 控制面创建方式最简单kind create cluster本地集群的通用部署步骤无论选择哪种本地集群接下来的步骤完全一致运行kubectl get nodes确认kubectl已连接到对应集群的控制面在仓库根目录执行skaffold run注意首次运行会比较慢可能耗时约 20 分钟需要拉取基础镜像、编译各语言服务并构建镜像。如果希望在重构代码时自动重建镜像并热更新部署改用skaffold devskaffold dev会监听源码变化一旦检测到文件改动便自动触发构建与重新部署非常适合本地迭代开发运行kubectl get pods确认所有 Pod 处于Running状态由于本地集群通常没有外部负载均衡器使用端口转发访问前端kubectl port-forward deployment/frontend 8080:8080浏览器访问localhost:8080即可看到前端页面。Online Boutique 前端商城页面部署成功后的运行效果四、深入理解 skaffold.yaml构建清单与配置画像要熟练使用上述命令理解仓库根目录的 skaffold.yaml 是关键。该文件声明了 Skaffold 的完整构建与部署行为分为两个Config段。主配置app构建全部核心服务apiVersion: skaffold/v3 kind: Config metadata: name: app build: platforms: [linux/amd64, linux/arm64] artifacts: - image: emailservice context: src/emailservice - image: productcatalogservice context: src/productcatalogservice ... - image: cartservice context: src/cartservice/src docker: dockerfile: Dockerfile - image: frontend context: src/frontend - image: adservice context: src/adservice tagPolicy: gitCommit: {} local: useDockerCLI: true useBuildkit: true manifests: kustomize: paths: - kubernetes-manifests deploy: kubectl: {}要点解读build.artifacts以“镜像名 构建上下文”的形式列出全部服务。注意cartservice的上下文是src/cartservice/src其Dockerfile位于该子目录即 src/cartservice/src/Dockerfile而其他服务的Dockerfile通常直接位于各自目录根例如 src/frontend/DockerfiletagPolicy.gitCommit镜像标签基于 Git commit 生成保证每次构建的可追溯性local.useDockerCLI/useBuildkit使用本地 Docker CLI 与 BuildKit 进行构建充分利用本机缓存manifests.kustomize.paths部署清单通过 Kustomize 组织指向 kubernetes-manifests 目录——该目录下的 kustomization.yaml 汇总了全部服务的 YAML 资源loadgenerator被注释掉因为开发期间它由独立的 Skaffold 模块单独管理见下文deploy.kubectl最终通过kubectl apply完成部署。独立配置loadgenerator负载生成器第二个Configmetadata.name: loadgenerator通过requires依赖主配置仅构建loadgenerator这一个镜像上下文 src/loadgenerator并直接使用原生 YAML 清单 kubernetes-manifests/loadgenerator.yaml 部署。这样在本地开发时可以单独控制是否注入模拟用户流量。内置 profileskaffold.yaml 定义了三个 profile可按需组合激活Profile激活方式作用gcbskaffold run -p gcb将构建后端切换到 Google Cloud Build无需本地 Docker适合 Google Cloud Shell 等磁盘受限环境缺点是 GCB 不缓存构建每次从零开始耗时较长debugskaffold debug自动激活将cartservice的Dockerfile替换为Dockerfile.debug开启可调试构建network-policiesskaffold run -p network-policies在 Kustomize 路径中追加 kustomize/components/network-policies 组件为服务应用网络策略其中debugprofile 体现了 Skaffold 与源码的深度集成src/frontend/Dockerfile中通过ARG SKAFFOLD_GO_GCFLAGS接收 Skaffold 传入的调试编译参数并设置GOTRACEBACKsingle方便定位问题。五、验证部署从 Pod 状态到端口转发无论使用哪种部署路径验证环节都一致kubectl get pods正常情况下你会看到adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、loadgenerator、paymentservice、productcatalogservice、recommendationservice、shippingservice以及 Redisredis-cart等 Pod 全部处于Running状态。在 GKE 上直接通过frontend-external的负载均衡 IP 访问在本地集群中则用kubectl port-forward deployment/frontend 8080:8080将 frontend Deployment 的 8080 端口转发到本机随后访问localhost:8080。frontend 的容器端口与健康检查细节可参考 kubernetes-manifests/frontend.yaml它以/_healthz作为就绪探针与存活探针路径并注入了PRODUCT_CATALOG_SERVICE_ADDR、CURRENCY_SERVICE_ADDR、CART_SERVICE_ADDR等服务发现环境变量用于在集群内定位各 gRPC 后端服务地址如productcatalogservice:3550、checkoutservice:5050。六、扩展如何添加一个新的微服务开发指南指出Online Boutique 的核心微服务集合已经比较完整、未来不太可能频繁变动但你可能希望添加一个可选的辅助微服务来补充功能。完整的分步指引见 docs/adding-new-microservice.md其核心流程包括在 src/ 目录下为服务创建新目录命名即服务名按照既有微服务的约定放置源码例如 Python 服务至少需要README.md、入口main.py、依赖清单requirements.in与Dockerfile编写Dockerfile可参考 src/frontend/Dockerfile 的多阶段构建与安全基线写法在 kustomize/components/ 下新增组件目录写入该服务的Deployment与Service清单并保证镜像名与构建配置一致——kustomize/components/shopping-assistant/ 是一个现成的完整参考示例它同时通过 patch 为frontend注入ENABLE_ASSISTANTtrue环境变量来启用新服务将新组件加入根级 kustomize/kustomization.yaml 的components列表在根级 skaffold.yaml 的build.artifacts中登记新服务确保镜像能被批量构建更新 helm-chart 的模板与默认 valueschart 版本信息见 helm-chart/Chart.yaml最后更新 README.md、docs/img 下的架构图或新增独立文档。这套流程体现了“仓库即配置中心”的设计skaffold.yaml负责构建编排kustomize负责清单组合Helm chart 提供可打包的发布形态三者通过一致的镜像命名与服务名相互衔接。七、清理部署当你完成开发或演示后如果应用是通过skaffold run部署的可以一键清理全部已部署资源skaffold delete该命令会依据skaffold.yaml中的部署配置删除之前skaffold run应用到集群的所有 Kubernetes 资源包括 Deployment、Service 等是本地反复迭代时的常用收尾操作。对于 GKE 路径还可以在确认清理后删除整个集群以停止计费。小结本文完整复现了 docs/development-guide.md 的两条部署路径并进一步剖析了 skaffold.yaml 的构建清单、profile 机制以及 src/frontend/Dockerfile 等源码层面的集成细节。核心要点可以概括为GKE 上用skaffold run --default-repo...一键上云本地用skaffold run/skaffold dev快速迭代skaffold delete完成清理。掌握这套流程后你既能基于 Online Boutique 快速搭建可复现的演示环境也能借助skaffold dev的自动重建能力高效地进行多语言微服务的本地开发与调试。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考