Skip to content

kubelet ignores optional CRI runtime conditions (kubelet will not rely on them, but it should somehow make them visible via kubectl) #123148

Open
@AkihiroSuda

Description

@AkihiroSuda

What happened?

The CRI API states that optional runtime conditions will be "exposed to users to help
them understand the status of the system", but the conditions are not visible via kubectl get nodes -o yaml. (Still visible via crictl info)

https://github.com/kubernetes/cri-api/blob/v0.29.1/pkg/apis/runtime/v1/api.proto#L1496-L1518

// RuntimeCondition contains condition information for the runtime.
// There are 2 kinds of runtime conditions:
// 1. Required conditions: Conditions are required for kubelet to work
// properly. If any required condition is unmet, the node will be not ready.
// The required conditions include:
//   * RuntimeReady: RuntimeReady means the runtime is up and ready to accept
//   basic containers e.g. container only needs host network.
//   * NetworkReady: NetworkReady means the runtime network is up and ready to
//   accept containers which require container network.
// 2. Optional conditions: Conditions are informative to the user, but kubelet
// will not rely on. Since condition type is an arbitrary string, all conditions
// not required are optional. These conditions will be exposed to users to help
// them understand the status of the system.
message RuntimeCondition {
    // Type of runtime condition.
    string type = 1;
    // Status of the condition, one of true/false. Default: false.
    bool status = 2;
    // Brief CamelCase string containing reason for the condition's last transition.
    string reason = 3;
    // Human-readable message indicating details about last transition.
    string message = 4;
}

What did you expect to happen?

The conditions should be visible via kubectl get nodes -o yaml

How can we reproduce it (as minimally and precisely as possible)?

  1. Implement an optional runtime condition cri: propagate deprecation list to runtime status containerd/containerd#9767
  2. Make sure that the added condition is visible via crictl info
  3. But the condition is not visible via kubectl get nodes -o yaml

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.1

Cloud provider

None

OS version

Linux

Install tools

Container runtime (CRI) and version (if applicable)

containerd v2 pre-release (https://github.com/containerd/containerd/pull/9767)

Related plugins (CNI, CSI, ...) and versions (if applicable)

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.sig/nodeCategorizes an issue or PR as relevant to SIG Node.

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions