The Role of SIG Node: How Kubernetes Optimizes Interaction Between Pods and Resources

Introduction

In Kubernetes, a Node represents a single machine in your cluster. SIG Node is responsible for these crucial Node components and supports various subprojects like Kubelet and Container Runtime Interface (CRI). In this blog, we’ve summarized our conversations with Elana Hashman (EH) and Sergey Kanzhelev (SK), who guide us through the various aspects of SIG membership and provide insights on how others can get involved.

Summary of Our Conversation

Could you tell us a bit about what SIG Node does?

SK: SIG Node is a vertical SIG responsible for the components that support controlled interactions between Pods and host resources. We manage the lifecycle of Pods scheduled on a Node. The focus of this SIG is to enable a broad range of workload types, including those with hardware-specific or performance-dependent requirements. We maintain the isolation boundaries between Pods on a Node as well as between Pod and host. This SIG manages a variety of components and has many external dependencies (like container runtimes or operating system features), which significantly increases the complexity we deal with. We tame this complexity and continuously strive to improve Node reliability.

“SIG Node is a vertical SIG” – could you elaborate on that?

EH: There are two types of SIGs: horizontal and vertical. Horizontal SIGs deal with a specific function of each component in Kubernetes: For example, SIG Security looks at the security aspects of each component, or SIG Instrumentation analyzes logs, metrics, traces, and events. Such SIGs typically don’t own much code.

Vertical SIGs, on the other hand, own a single component and are responsible for approving and merging patches into that codebase. SIG Node belongs to the “Node” vertical, which relates to the Kubelet and its lifecycle. This includes the code for the Kubelet itself, as well as the Node Controller, the Container Runtime Interface, and related subprojects like the Node Problem Detector.

How did the CI subproject come about? Is it specific to SIG Node and how does it help the SIG?

SK: The subproject emerged after one of the releases was blocked due to numerous test failures of critical tests. These tests didn’t all fail at once, but continuous neglect led to a slow degradation of test quality. SIG Node has always prioritized quality and reliability, and the formation of the subproject was a way to emphasize this priority.

As the third largest SIG in terms of the number of issues and PRs, how does your SIG manage so much work?

EH: It helps to be organized. When I increased my contributions to the SIG in January 2021, I felt overwhelmed by the number of pull requests and issues and didn’t know where to start. We were already tracking test-related issues and pull requests on the CI subproject board, but that missed many of our bug fixes and feature work. So, I began compiling a triage board for the remaining pull requests, which allowed me to sort each by status and required actions and document its use for other contributors. Over the last two releases, we’ve closed or merged over 500 issues and pull requests tracked by our two boards. The Kubernetes Devstats showed that as a result, we’ve significantly increased our velocity.

In June, we held our first bug scrub event to work through the backlog of issues filed against SIG Node and ensure they were properly categorized. During this 48-hour global event, we closed over 130 issues, but at the time of writing, we still have 333 open issues.

Ayedo is proud to act as a partner in the Kubernetes ecosystem, supporting teams in leveraging the benefits of SIG Node and other Kubernetes initiatives.

Source: Kubernetes Blog