此内容没有您所选择的语言版本。

Chapter 1. Troubleshooting RuntimeClass


Diagnose and resolve common build configuration errors related to RuntimeClass isolation. Identifying these issues ensures that builds run in the intended isolated environments and helps maintain cluster security.

1.1. Resolving build failures with RuntimeClassNameNotValid

If the runtimeClassName value violates DNS subdomain naming conventions, the Build or BuildRun status is set to RuntimeClassNameNotValid.

Procedure

  1. Run the following command to check the build status:

    $ oc get build buildah-build-kata -o jsonpath='{.status.reason}'
  2. To fix this issue, update the runtimeClassName to use only lowercase alphanumeric characters, dots (.), or hyphens (-), and ensure it begins and ends with an alphanumeric character.

    The following example output displays the invalid names:

runtimeClassName: My_Runtime!  # Invalid: uppercase, underscore, and special character
runtimeClassName: Kata         # Invalid: uppercase letter
runtimeClassName: -kata        # Invalid: starts with hyphen

+ The following example output displays the valid names:

runtimeClassName: kata              # Valid
runtimeClassName: gvisor.runsc      # Valid: contains dot
runtimeClassName: kata-containers   # Valid: contains hyphen

1.2. Resolving build pods in Pending state

When a build pod fails to schedule, examine the pod events for diagnostic details to identify the root cause.

Procedure

  1. Run the following command to examine the pod events:

    $ oc describe pod <build-pod-name>
  2. Identify any FailedScheduling events, which often result from the following scenarios:

    • The Build validation only checks string format, a name that is syntactically valid but refers to a missing RuntimeClass will fail during scheduling. Run the following command to verify the resource exists:

      $ oc get runtimeclass kata
    • The targeted nodes must have the Kata runtime properly installed. Confirm the KataConfig status and node readiness:

      $ oc get kataconfig -o yaml

      Check status.installationStatus to ensure the installation on worker nodes was successful.

    • The operator-managed kata runtimeClass applies a node-role.kubernetes.io/kata-oc: "" selector. If your build configuration defines additional selectors, they must intersect with the runtimeClass requirements. Verify node labels:

      $ oc get nodes --show-labels | grep kata

The BuildRunBuildFieldOverrideForbidden error occurs if you try to set runtimeClassName on a BuildRun that has an embedded spec.build.spec rather than a reference to a named Build.

Procedure

  1. Run the following command to check the BuildRun status message:

    $ oc get buildrun <buildrun-name> -o jsonpath='{.status.conditions[0].message}'
  2. To resolve this issue, use one of the following methods:

    1. Define the runtimeClassName directly within the inline spec.build.spec block:

      apiVersion: shipwright.io/v1beta1
      kind: BuildRun
      spec:
        build:
          spec:
            # ... source and strategy fields ...
            runtimeClassName: kata
    2. Reference a standalone Build by name to use the override field:

      apiVersion: shipwright.io/v1beta1
      kind: BuildRun
      spec:
        build:
          name: buildah-build-kata
        runtimeClassName: kata

If events report that the runtimeClass is missing, the operator setup might be incomplete.

Procedure

  1. Confirm the operator is active:

    $ oc get csv -n openshift-sandboxed-containers-operator
  2. Check the KataConfig installation status:

    $ oc get kataconfig -o jsonpath='{.items[0].status.installationStatus}'
  3. Ensure all worker nodes have completed the mandatory reboot process.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部