[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],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)."]]