Add SIG Node Spolight
Co-authored-by: Arpit Agrawal <72355275+Hii-Arpit@users.noreply.github.com> Co-authored-by: Laura Santamaria <nimbinatus@users.noreply.github.com> Co-authored-by: Sandeep Kanabar <sandeepkanabar@gmail.com> Co-authored-by: Tim Bannister <tim@scalefactory.com>pull/46774/head
Frederico Muñoz
parent
fa12882dbb
commit
37efe6f2c6
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
|
|
@ -0,0 +1,226 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Spotlight on SIG Node"
|
||||
slug: sig-node-spotlight-2024
|
||||
canonicalUrl: https://www.kubernetes.dev/blog/2024/06/20/sig-node-spotlight-2024
|
||||
date: 2024-06-20
|
||||
author: >
|
||||
Arpit Agrawal
|
||||
---
|
||||
|
||||
|
||||
In the world of container orchestration, [Kubernetes](/) reigns
|
||||
supreme, powering some of the most complex and dynamic applications across the globe. Behind the
|
||||
scenes, a network of Special Interest Groups (SIGs) drives Kubernetes' innovation and stability.
|
||||
|
||||
Today, I have the privilege of speaking with [Matthias
|
||||
Bertschy](https://www.linkedin.com/in/matthias-bertschy-b427b815/), [Gunju
|
||||
Kim](https://www.linkedin.com/in/gunju-kim-916b33190/), and [Sergey
|
||||
Kanzhelev](https://www.linkedin.com/in/sergeykanzhelev/), members of [SIG
|
||||
Node](https://github.com/kubernetes/community/blob/master/sig-node/README.md), who will shed some
|
||||
light on their roles, challenges, and the exciting developments within SIG Node.
|
||||
|
||||
_Answers given collectively by all interviewees will be marked by their initials._
|
||||
|
||||
## Introductions
|
||||
|
||||
**Arpit:** Thank you for joining us today. Could you please introduce yourselves and provide a brief
|
||||
overview of your roles within SIG Node?
|
||||
|
||||
**Matthias:** My name is Matthias Bertschy, I am French and live next to Lake Geneva, near the
|
||||
French Alps. I have been a Kubernetes contributor since 2017, a reviewer for SIG Node and a
|
||||
maintainer of [Prow](https://docs.prow.k8s.io/docs/overview/). I work as a Senior Kubernetes
|
||||
Developer for a security startup named [ARMO](https://www.armosec.io/), which donated
|
||||
[Kubescape](https://www.cncf.io/projects/kubescape/) to the CNCF.
|
||||
|
||||
|
||||
|
||||
**Gunju:** My name is Gunju Kim. I am a software engineer at
|
||||
[NAVER](https://www.navercorp.com/naver/naverMain), where I focus on developing a cloud platform for
|
||||
search services. I have been contributing to the Kubernetes project in my free time since 2021.
|
||||
|
||||
**Sergey:** My name is Sergey Kanzhelev. I have worked on Kubernetes and [Google Kubernetes
|
||||
Engine](https://cloud.google.com/kubernetes-engine) for 3 years and have worked on open-source
|
||||
projects for many years now. I am a chair of SIG Node.
|
||||
|
||||
## Understanding SIG Node
|
||||
|
||||
**Arpit:** Thank you! Could you provide our readers with an overview of SIG Node's responsibilities
|
||||
within the Kubernetes ecosystem?
|
||||
|
||||
**M/G/S:** SIG Node is one of the first if not the very first SIG in Kubernetes. The SIG is
|
||||
responsible for all iterations between Kubernetes and node resources, as well as node maintenance
|
||||
itself. This is quite a large scope, and the SIG owns a large part of the Kubernetes codebase. Because
|
||||
of this wide ownership, SIG Node is always in contact with other SIGs such as SIG Network, SIG
|
||||
Storage, and SIG Security and almost any new features and developments in Kubernetes involves SIG
|
||||
Node in some way.
|
||||
|
||||
**Arpit**: How does SIG Node contribute to Kubernetes' performance and stability?
|
||||
|
||||
**M/G/S:** Kubernetes works on nodes of many different sizes and shapes, from small physical VMs
|
||||
with cheap hardware to large AI/ML-optimized GPU-enabled nodes. Nodes may stay online for months or
|
||||
maybe be short-lived and be preempted at any moment as they are running on excess compute of a cloud
|
||||
provider.
|
||||
|
||||
[`kubelet`](/docs/concepts/overview/components/#kubelet) — the
|
||||
Kubernetes agent on a node — must work in all these environments reliably. As for the performance
|
||||
of kubelet operations, this is becoming increasingly important today. On one hand, as Kubernetes is
|
||||
being used on extra small nodes more and more often in telecom and retail environments, it needs to
|
||||
scale into the smallest footprint possible. On the other hand, with AI/ML workloads where every node
|
||||
is extremely expensive, every second of delayed operations can visibly change the price of
|
||||
computation.
|
||||
|
||||
|
||||
## Challenges and Opportunities
|
||||
|
||||
**Arpit:** What upcoming challenges and opportunities is SIG Node keeping an eye on?
|
||||
|
||||
**M/G/S:** As Kubernetes enters the second decade of its life, we see a huge demand to support new
|
||||
workload types. And SIG Node will play a big role in this. The Sidecar KEP, which we will be talking
|
||||
about later, is one of the examples of increased emphasis on supporting new workload types.
|
||||
|
||||
The key challenge we will have in the next few years is how to keep innovations while maintaining
|
||||
high quality and backward compatibility of existing scenarios. SIG Node will continue to play a
|
||||
central role in Kubernetes.
|
||||
|
||||
**Arpit:** And are there any ongoing research or development areas within SIG Node that excite you?
|
||||
|
||||
**M/G/S:** Supporting new workload types is a fascinating area for us. Our recent exploration of
|
||||
sidecar containers is a testament to this. Sidecars offer a versatile solution for enhancing
|
||||
application functionality without altering the core codebase.
|
||||
|
||||
**Arpit:** What are some of the challenges you've faced while maintaining SIG Node, and how have you
|
||||
overcome them?
|
||||
|
||||
**M/G/S:** The biggest challenge of SIG Node is its size and the many feature requests it
|
||||
receives. We are encouraging more people to join as reviewers and are always open to improving
|
||||
processes and addressing feedback. For every release, we run the feedback session at the SIG Node
|
||||
meeting and identify problematic areas and action items.
|
||||
|
||||
**Arpit:** Are there specific technologies or advancements that SIG Node is closely monitoring or
|
||||
integrating into Kubernetes?
|
||||
|
||||
**M/G/S:** Developments in components that the SIG depends on, like
|
||||
[container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
(e.g. [containerd](https://containerd.io/) and [CRI-O](https://cri-o.io/), and OS features are
|
||||
something we contribute to and monitor closely. For example, there is an upcoming _cgroup v1_
|
||||
deprecation and removal that Kubernetes and SIG Node will need to guide Kubernetes users
|
||||
through. Containerd is also releasing version `2.0`, which removes deprecated features, which will
|
||||
affect Kubernetes users.
|
||||
|
||||
**Arpit:** Could you share a memorable experience or achievement from your time as a SIG Node
|
||||
maintainer that you're particularly proud of?
|
||||
|
||||
**Mathias:** I think the best moment was when my first KEP (introducing the
|
||||
[`startupProbe`](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes))
|
||||
finally graduated to GA (General Availability). I also enjoy seeing my contributions being used
|
||||
daily by contributors, such as the comment containing the GitHub tree hash used to retain LGTM
|
||||
despite squash commits.
|
||||
|
||||
## Sidecar containers
|
||||
|
||||
**Arpit:** Can you provide more context on the concept of sidecar containers and their evolution in
|
||||
the context of Kubernetes?
|
||||
|
||||
**M/G/S:** The concept of
|
||||
[sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/) dates back to
|
||||
2015 when Kubernetes introduced the idea of composite containers. These additional containers,
|
||||
running alongside the main application container within the same pod, were seen as a way to extend
|
||||
and enhance application functionality without modifying the core codebase. Early adopters of
|
||||
sidecars employed custom scripts and configurations to manage them, but this approach presented
|
||||
challenges in terms of consistency and scalability.
|
||||
|
||||
**Arpit:** Can you share specific use cases or examples where sidecar containers are particularly
|
||||
beneficial?
|
||||
|
||||
**M/G/S:** Sidecar containers are a versatile tool that can be used to enhance the functionality of
|
||||
applications in a variety of ways:
|
||||
|
||||
- **Logging and monitoring:** Sidecar containers can be used to collect logs and metrics from the
|
||||
primary application container and send them to a centralized logging and monitoring system.
|
||||
- **Traffic filtering and routing:** Sidecar containers can be used to filter and route traffic to
|
||||
and from the primary application container.
|
||||
- **Encryption and decryption:** Sidecar containers can be used to encrypt and decrypt data as it
|
||||
flows between the primary application container and external services.
|
||||
- **Data synchronization:** Sidecar containers can be used to synchronize data between the primary
|
||||
application container and external databases or services.
|
||||
- **Fault injection:** Sidecar containers can be used to inject faults into the primary application
|
||||
container in order to test its resilience to failures.
|
||||
|
||||
**Arpit:** The proposal mentions that some companies are using a fork of Kubernetes with sidecar
|
||||
functionality added. Can you provide insights into the level of adoption and community interest in
|
||||
this feature?
|
||||
|
||||
**M/G/S:** While we lack concrete metrics to measure adoption rates, the KEP has garnered
|
||||
significant interest from the community, particularly among service mesh vendors like Istio, who
|
||||
actively participated in its alpha testing phase. The KEP's visibility through numerous blog posts,
|
||||
interviews, talks, and workshops further demonstrates its widespread appeal. The KEP addresses the
|
||||
growing demand for additional capabilities alongside main containers in Kubernetes pods, such as
|
||||
network proxies, logging systems, and security measures. The community acknowledges the importance
|
||||
of providing easy migration paths for existing workloads to facilitate widespread adoption of the
|
||||
feature.
|
||||
|
||||
**Arpit:** Are there any notable examples or success stories from companies using sidecar containers
|
||||
in production?
|
||||
|
||||
**M/G/S:** It is still too early to expect widespread adoption in production environments. The 1.29
|
||||
release has only been available in Google Kubernetes Engine (GKE) since January 11, 2024, and there
|
||||
still needs to be comprehensive documentation on how to enable and use them effectively via
|
||||
universal injector. Istio, a popular service mesh platform, also lacks proper documentation for
|
||||
enabling native sidecars, making it difficult for developers to get started with this new
|
||||
feature. However, as native sidecar support matures and documentation improves, we can expect to see
|
||||
wider adoption of this technology in production environments.
|
||||
|
||||
**Arpit:** The proposal suggests introducing a `restartPolicy` field for init containers to indicate
|
||||
sidecar functionality. Can you explain how this solution addresses the outlined challenges?
|
||||
|
||||
**M/G/S:** The proposal to introduce a `restartPolicy` field for init containers addresses the
|
||||
outlined challenges by utilizing existing infrastructure and simplifying sidecar management. This
|
||||
approach avoids adding new fields to the pod specification, keeping it manageable and avoiding more
|
||||
clutter. By leveraging the existing init container mechanism, sidecars can be run alongside regular
|
||||
init containers during pod startup, ensuring a consistent ordering of initialization. Additionally,
|
||||
setting the restart policy of sidecar init containers to `Always` explicitly states that they continue
|
||||
running even after the main application container terminates, enabling persistent services like
|
||||
logging and monitoring until the end of the workload.
|
||||
|
||||
**Arpit:** How will the introduction of the `restartPolicy` field for init containers affect
|
||||
backward compatibility with existing Kubernetes configurations?
|
||||
|
||||
**M/G/S:** The introduction of the `restartPolicy` field for init containers will maintain backward
|
||||
compatibility with existing Kubernetes configurations. Existing init containers will continue to
|
||||
function as they have before, and the new `restartPolicy` field will only apply to init containers
|
||||
explicitly marked as sidecars. This approach ensures that existing applications and deployments will
|
||||
not be disrupted by the new feature, and provides a more streamlined way to define and manage
|
||||
sidecars.
|
||||
|
||||
## Contributing to SIG Node
|
||||
|
||||
**Arpit:** What is the best place for the new members and especially beginners to contribute?
|
||||
|
||||
**M/G/S:** New members and beginners can contribute to the Sidecar KEP (Kubernetes Enhancement
|
||||
Proposal) by:
|
||||
|
||||
- **Raising awareness:** Create content that highlights the benefits and use cases of sidecars. This
|
||||
can educate others about the feature and encourage its adoption.
|
||||
- **Providing feedback:** Share your experiences with sidecars, both positive and negative. This
|
||||
feedback can be used to improve the feature and make it more widely usable.
|
||||
- **Sharing your use cases:** If you are using sidecars in production,
|
||||
share your experiences with others. This can help to demonstrate the
|
||||
real-world value of the feature and encourage others to adopt it.
|
||||
- **Improving the documentation:** Help to clarify and expand the documentation for the
|
||||
feature. This can make it easier for others to understand and use sidecars.
|
||||
|
||||
In addition to the Sidecar KEP, there are many other areas where SIG Node needs more contributors:
|
||||
|
||||
- **Test coverage:** SIG Node is always looking for ways to improve the test coverage of Kubernetes
|
||||
components.
|
||||
- **CI maintenance:** SIG Node maintains a suite of e2e tests ensuring Kubernetes components
|
||||
function as intended across a variety of scenarios.
|
||||
|
||||
|
||||
# Conclusion
|
||||
|
||||
In conclusion, SIG Node stands as a cornerstone in Kubernetes' journey, ensuring its reliability and
|
||||
adaptability in the ever-changing landscape of cloud-native computing. With dedicated members like
|
||||
Matthias, Gunju, and Sergey leading the charge, SIG Node remains at the forefront of innovation,
|
||||
driving Kubernetes towards new horizons.
|
||||
Loading…
Reference in New Issue