Cloud Run 是一个代管式计算平台,供您运行可通过 Web 请求或 Pub/Sub 事件调用的无状态容器。简化的 Linux 服务管理器允许您在 Cloud Run 上部署迁移的容器工作负载。
将工作负载身份与 Migrate to Containers 和 GKE 搭配使用
借助 Migrate to Containers and GKE,您可以将迁移后的工作负载部署到 Google Distributed Cloud。有时,您可能会使用与处理集群和部署集群相同的集群。如果您已在部署集群上启用工作负载身份,请确保配置部署环境以支持 Migrate to Containers 和 GKE。
此外,您还必须确保为 Workload Identity 正确配置在 init 过程中启动的所有服务。您执行的步骤取决于集群的服务管理器。如需了解配置步骤,请参阅将 Linux 工作负载部署到目标集群。
相对于现有运行时的变化
如需使用简化的 Linux 服务管理器,您应了解现有运行时的以下更改和限制。
添加了新的 services-config.yaml 工件文件
如果启用了简化的 Linux 服务管理器,Migrate to Containers 会在生成迁移工件时创建新的工件文件 services-config.yaml。使用此文件可控制已部署容器上的应用初始化。如需了解详情,请参阅使用 services-config.yaml。
就绪性探测
使用当前运行时时,Migrate to Containers 会在 deployment_spec.yaml 文件中添加就绪性探测。启用简化的 Linux 服务管理器后,系统不会添加就绪性探测。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-19。"],[],[],null,["# New enhanced runtime\n====================\n\nThe original Linux service manager for Migrate to Containers relied\non `sysv init` and `systemd`. The simplified Linux service manager\nreplaces it with a simplified, container friendly alternative.\n\nThis simplified Linux service manager adds functionality that lets you deploy\nyour migrated container workloads to:\n\n- **GKE Autopilot clusters**\n\n- **Cloud Run**\n\nThe simplified Linux service manager also resolves compatibility issues with Kubernetes plugins.\nFor example, the simplified Linux service manager removes the requirement of defining a `hostpath`\nfor `/sys/fs/cgroup` in the `deployment_spec.yaml` file and the need to create\nprivileged containers.\n\n### Before you begin\n\n- Migrate to Containers supplies a tool that you run on a VM workload to determine the *fit* of the workload for migration to a container. For more information, see [Using the fit assessment tool](/migrate/containers/docs/fit-assessment).\n\n### About GKE Autopilot clusters\n\nAutopilot is a mode of operation in Google Kubernetes Engine (GKE). Autopilot is designed to\nreduce the operational cost of managing clusters, optimize your clusters for production,\nand yield higher workload availability. In Autopilot mode, GKE\nprovisions and manages the underlying infrastructure of the cluster, including nodes and\nnode pools, giving you an optimized cluster with an automated experience.\n| **Note:** Autopilot is supported for GKE clusters but is not supported for GKE Enterprise clusters.\n\nSee [Autopilot overview](/kubernetes-engine/docs/concepts/autopilot-overview) for more details.\n\n### About Cloud Run\n\n[Cloud Run](/run/docs) is a managed compute platform that enables you to\nrun stateless containers that are invokable by web requests or Pub/Sub events.\nThe simplified Linux service manager lets you deploy your migrated container workloads on Cloud Run.\n| **Note:** The container workload must be stateless to be deployed on Cloud Run. See [Developing your service](/run/docs/developing) for more information, including the complete list of requirements for deploying containers on Cloud Run.\n\n### Using workload identity with Migrate to Containers and GKE\n\nMigrate to Containers and GKE let you deploy your\nmigrated workloads to [Google Distributed Cloud](/anthos/clusters/docs/bare-metal).\nSometimes, you might use the same cluster as both the processing cluster and the deployment cluster.\nIf you have enabled workload identity on your deployment cluster, ensure that you configure your deployment environment to support Migrate to Containers and GKE.\n\nAlso, you must ensure that any services started as part of the init\nprocess are configured correctly for workload identity. The steps you perform depend on\nthe service manager for your cluster.\nSee [Deploying a Linux workload to a target cluster](/migrate/containers/docs/deploying-to-target-cluster)\nfor the configuration steps.\n\nChanges from the existing runtime\n---------------------------------\n\nTo use the simplified Linux service manager, you should be aware of the following\nchanges and limitations from the existing runtime.\n\n### New services-config.yaml artifact file added\n\nIf you enable the simplified Linux service manager, Migrate to Containers creates a new artifact file,\n`services-config.yaml`, when you generate the migration artifacts. Use this file to control\napplication initialization on a deployed container. See [Using services-config.yaml](/migrate/containers/docs/services-config)\nfor more information.\n| **Note:** The `services-config.yaml` is only created when you perform a **new** migration using Migrate to Containers version 1.15.0. It is not created when you convert an existing migration from a previous version to version 1.15.0.\n\n### Readiness probes\n\nWhen using the current runtime, Migrate to Containers adds a readiness probe in\nthe `deployment_spec.yaml` file. When you enable the simplified Linux service manager,\nno readiness probe is added.\n\nIf you want to add a readiness probe, we recommend that you use an HTTP readiness probe.\nSee [Define readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)\nfor more information.\n**Note:** You can add the simplified Linux service manager readiness probe to your Service definition: \n\n readinessProbe:\n exec:\n command:\n - /.m4a/gamma status\n\nHowever, this probe might return a false negative result.\n\n### syslog support\n\nThe simplified Linux service manager creates a Unix socket at `/dev/log` to support the syslog.\nThe simplified Linux service manager forwards these log messages to `stdout` so that they are\nrecorded by Kubernetes as container logs.\n\n### Limitations\n\nYou should be aware of the following limitations when using the simplified\nLinux service manager.\n\n#### Workload limitations\n\nThe simplified Linux service manager works best with the following types of workloads:\n\n#### systemd limitations\n\nIf you're using `systemd` as your init system, be aware of the following limitations:\n\n- `systemd` service [types](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=)\n of `simple`,`exec`, and `notify` are treated as `exec` service. That means the\n service is considered started, when `exec` succeeds.\n\n- Notify sockets are supported for\n [sd_notify()](https://www.freedesktop.org/software/systemd/man/sd_notify.html#)\n for `READY=1` messages only.\n\n If needed, you can provide other readiness checks. For example, HTTP check\n or other types of check.\n- Socket type unit files are not supported. Sockets are not created and no environment variables are created.\n\nUpdates for version 1.9.0\n-------------------------\n\nThe simplified Linux service manager for version 1.9.0 contains the following updates:\n\n- The Linux service manager has been released for general availability, and is no longer\n in Public Preview.\n\n- The procedure to [Convert existing container workloads to support Autopilot](/migrate/containers/docs/convert-runtime)\n has been changed. You now need to edit both the Dockerfile and the\n `deployment_spec.yaml` file for an existing migration to convert it.\n\n- The `config.yaml` file has been renamed to `services-config.yaml`.\n\nUpdates for version 1.8.1\n-------------------------\n\nThe simplified Linux service manager was originally released in Public Preview as part of\nMigrate to Containers version 1.8. The simplified Linux service manager for version 1.8.1\ncontains the following updates:\n\n- You no longer set an annotation in the migration plan to enable the simplified\n Linux service manager. Instead, you now set `v2kServiceManager`.\n See [Deploy containers to Autopilot clusters](/migrate/containers/docs/deploy-autopilot)\n for more.\n\n- The environment variable `HC_GAMMA_RUNTIME` has been renamed to `HC_V2K_SERVICE_MANAGER`.\n\n- The `prestart` and `poststart` entries in the `services-config.yaml` file now automatically populated.\n See [Using services-config.yaml](/migrate/containers/docs/services-config)\n for more.\n\n- Added support to the `services-config.yaml` file that lets you specify environment variables\n at the global level or at the application level.\n See [Using services-config.yaml](/migrate/containers/docs/services-config)\n for more.\n\n- Added logging support that lets you customize log data written to Cloud Logging.\n See [Customize log data written to Cloud Logging](/migrate/containers/docs/customizing-a-migration-plan#log-files)\n for more.\n\nWhat's next\n-----------\n\n- Learn how to [migrate and deploy applications to GKE Autopilot clusters](/migrate/containers/docs/deploy-autopilot)."]]