community
community copied to clipboard
kubernetes
Unconference Topics - Kubernetes Contributor Summit 2024 Paris
Describe the issue
Bonjour Kubernetes friends! 🇫🇷
Exciting news – we're organizing Unconference for this year's Kubernetes Contributor Summit in Paris and we'd love to know what topics interest you. Feel free to suggest a topic or give a thumbs up to ones that catch your eye. Our goal is to gauge the community's general interests, not just those attending in person :)
You can suggest by dropping a comment with - Topic: [Your Topic] Description: [Brief Description] Moderator: [Planning to attend in person and want to moderate? (yes, maybe or no)]
To upvote, simply use the :+1: emoji.
If you have any questions, reach out to me @fykaa (fyka in Slack).
Thanks a bunch! – Faeka Ansari, KCEU K8s Contributor Summit 2024 Content Lead
You can find session notes here: k8s.dev/summit/notes
Topic: Future of Events on Kubernetes
Description:
Events in Kubernetes are sometimes the only source for information that users find helpful (such as exit codes returned by health checks). End-users consistently treat events as a reliable delivery bus for this information and many articles across the internet imply that they are this, but in truth this is not guaranteed by us, in fact we actually intentionally refuse to deliver them under very strict rate limits. We also currently make no guarantees that events won't be removed in future versions, breaking potential underlying implementations.
Is there anything we can do to help these folks? Do we want to revisit events in the long term as concept? Come to this session to discuss our current approach and brainstorm what we'd like to change about events over the next few years, if anything.
Moderator: @intUnderflow, also open to others who have more experience moderating this instead 👍🏻
Topic: Revisiting Kubernetes Hardware Resource Model
Description:
The advent of AI/ML workloads has brought the need for improved management of scarce and expensive resources within Kubernetes. The current resource management in Kubernetes has grown organically over the years to add features like extended resources and subsystems like the CPU, Memory, and Topology managers. New efforts are underway at various stages as well, including DRA, mutable node resources, QoS class resources, in-place Pod resource updates, and others.
Each of these efforts has been designed with different use cases and constraints in mind, and with different levels of integration to the scheduler and auto-scaler. For example, extended resources are considered by the scheduler, but topology alignment is not. Similarly, the cluster autoscaler and tools like Karpenter may lack visibility into how new nodes may satisfy workload resource demands that go beyond the basics. At the same time technologies like NVLink and Ultra Ethernet are dictating new hardware configurations and topologies beyond the intra-node topologies currently understood by Kubernetes.
We also have efforts that are pushing the envelope in the other direction, building more scheduling features, with more sophisticated job controllers and gang scheduling. These use cases need more data than can be provided by the underlying model today, especially if they are to take advantage of inter- and intra-node topologies to get the best performance out of the hardware.
In the work on the latest versions of DRA, we are seeing hints at a more holistic model that can scale both downward to intra-node topology, as well as upward to multi-node topologies. We would like to discuss this with the community, learn about different use cases, and brainstorm ways to divide this up into a series of tractable problems.
Document for discussion: Revisiting Kubernetes Hardware Resource Model
Please contribute to the notes
Moderators
- @dchen1107
- @jeremyeder
- @johnbelamaric
- @jonathan-innis
- @kad
- @klueska
- @mwielgus
- @pohly
- @thockin
Topic: ClusterInventory API access/credentials
Description: KEP-4322: Inventory Cluster API is a proposal to establish a standardized inventory cluster API to represent clusters in a multicluster deployment. We have use cases to use this to facilitate API access to each of the various clusters, but its not currently in scope of the first phase of the API.
A subgroup of SIG-MC has however started discussions on the topic of representing/storing access credentials and the relevant access patterns; see the working document for details. The target audience is controllers needing access to all the clusters in a clusterset, or at least some pattern providing access to all the clusters in a clusterset. As usual for SIG-MC, we want to avoid locking in certain implementation choices, but we do want to ensure the spec is useful and usable without (much) extension.
A number of people are interested in continuing the discussion face to face at the contributor summit. Current open questions include
- Spec vs status
- TTL/refresh rate
- Optional/required/recommended?
- How to handle credentials that may be application specific?
- Should controllers using Clusterinventory be local and use local permissions to write to the same cluster or should they be able to reach into the cluster:
- Push vs Pull (the clusterinventoried cluster pulls config vs the management cluster pushes down)
- Potential architectures and how that could impact our discussion
- Is it good enough to have admin credentials; do we need to support more fine grained credentials e.g. per controller
- What is the use case for colocating ClusterInventory API in a cluster that isn’t trusted enough to get admin creds
Moderator: @skitt, other volunteers are welcome!
Topic: Enabling SIGs to acknowledge, recognize, and manage Non-Code contributions.
Description: We all know that there are more contributions to open source than just lines of code, but how do we deal with them? We're addressing questions like:
- What types of non-code roles exist today?
- How do we Identify them? How are these types of roles and tasks seen today?
- Are these contributions tracked? How are they/could they be tracked?
- How do we Publicize them and make them Actionable?
- How do you attract new contributors to these roles and tasks?
- What could a contributor ladder look like for these?
We really need additional SIGs onboard with this initiative to help us to help you. We will be visiting many SIGs in the near future to talk about these topics, but early commitment from SIG leadership will help our research and help us define a framework for all SIGs and WGs, and eventually all CNCF projects to use, as mentioned here: https://github.com/cncf/tag-contributor-strategy/issues/82
Moderator: @qedrakmar
KCSEU 2024 event is over. :slightly_smiling_face:
@fykaa, are we good to close this issue now? Thanks!
@ameukam: Closing this issue.
In response to this:
Retro - part 2 is done.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
