Skip to content

README.md

Latest commit

 

History

History
261 lines (220 loc) · 16.3 KB

README.md

File metadata and controls

261 lines (220 loc) · 16.3 KB

Network Special Interest Group

Covers networking in Kubernetes.

The charter defines the scope and governance of the Network Special Interest Group.

Meetings

Joining the mailing list for the group will typically add invites for the following meetings to your calendar.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing subprojects, and resolve cross-subproject technical issues and decisions.

Emeritus Leads

Contact

Working Groups

The following working groups are sponsored by sig-network:

Subprojects

The following subprojects are owned by sig-network:

cluster-proportional-autoscaler

cluster-proportional-vertical-autoscaler

external-dns

gateway-api

gateway-api-inference-extension

Gateway API Inference Extension

ingate

ingress

iptables-wrappers

kindnet

knftables

kube-agentic-networking

kube-dns

kubernetes-network-drivers

multi-network

network-policy

node-ipam-controller

pod-networking

wg-ai-gateway

Proposals and discussions for the AI Gateway Working Group

Subproject Leads

SIG network provides some additional responsibilities for subproject leads beyond what is covered in the standard subproject definition. Most of these additional responsibilities relate to communication about their projects within SIG Network, and to the greater community:

  • Transparent Project Planning, Maintenance and Communication:

    • Subproject Leads must provide transparent view into their historical and future project plans (eg; using GitHub project boards, KEPs, or custom enhancement proposals (see GEPs/NPEPs)).
    • Subproject leads must create, maintain and be present in a public Kubernetes Slack channel with the easy-to-find naming #sig-network-<subproject> for their sub-project.
    • Subproject leads should create and maintain a regular public Zoom sync on the SIG Network Calendar.
    • Subproject leads must keep the project in good health through regular issue triaging, PR reviews, CI health monitoring and checking testgrids (delegating this to other members in the community is good!)
    • Projects that own CRDs in the k8s.io group must go through the API review process and Subproject leads are expected to make sure this well defined processes across Kubernetes is followed.

  • Regular Project Updates

    • Subproject leads must report on project's status, significant releases/events, interesting developments to the wider SIG-Network community via the SIG Network Mailing List on a quarterly basis (or as needed).
    • Subproject leads should report on project status in the general SIG Network community meetings (in addition to mailing list updates).

Areas of Responsibility

SIG Network is responsible for the following Kubernetes subsystems:

  • DNS
  • Ingress
  • Network plugins / CNI
  • Network Policy
  • Services / kube-proxy

SIG Network is responsible for a number of issues and PRs. A summary can be found through GitHub search:

Documents

Archive

The following are larger efforts which are now archived and historical. They are no longer active, but are kept in an archived state for posterity and maybe be useful as reference materials.

KPNG

"Kube Proxy Next Generation (KPNG)" was an effort to evaluate the potential for a new kube-proxy with an emphasis on modularity and adaptability. Through the project we explored alternatives to our historical kube-proxy architecture and gained a lot of community members through interest in it. The project was very large in scope, and was archived in 2024 after agreement that the community was no longer able to continue focus on it, but it remains important prior art for any future attempts to revise kube-proxy.

Blixt

Blixt was a Kubernetes L4 load-balancer that started in the early 2020's at a time when eBPF technology was a huge buzz for Kubernetes, and members of the Kubernetes SIG Network community wanted to experiment with and explore the technology on K8s. The project operated primarily as an experimental sandbox.

We had a lot of fun working on this while it was active. It was great to create the first official Kubernetes project in Rust, and experimenting with eBPF in its nascence was exciting. All things must come to an end however. Thank you to all contributors!