Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

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

1.3. Resolve buildRun failures with BuildRunBuildFieldOverrideForbidden

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

1.4. Resolving build pod failures with RuntimeClass not found error

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

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat Dokumentation

Legal Notice

Theme

© 2026 Red Hat
Nach oben