![\"Selfie](\"\/img\/kubecon-eu-2026-selfie.jpg\")
<\/p>\n\nAs is becoming tradition, here is my bi-annual update to this blog with my thoughts and perceptions\nfrom another KubeCon. This time for the Spring 2026 KubeCon in Europe. TL;DR Lots of\nexcitement for Kubernetes, more people than Atlanta, AI fatigue is setting in, scheduling is getting\nbigger, and as always excellent hallway track conversations.<\/p>\n\n
KubeCon was held at the RAI center in Amsterdam Netherlands this year, the same venue we were at for\nKubeCon in 2023. The RAI is a large venue and KubeCon filled it nicely, but not overly so. This year\nmy schedule was quite packed with the Maintainer Summit happening on Sunday, the Workload Aware Scheduling\nDesign Summit on Monday, and then KubeCon proper from Tuesday through Thursday. I spoke on two panels\nduring KubeCon and was generally quite exhausted by the end of the week, but I had a great time and KubeCon\ncontinues to be a great investment of time and energy for me.<\/p>\n\n
As is becoming a sad tradition, the political world is lighting itself on fire as KubeCon is happening, with\nthe war in Iran being a constant note in the background. Thankfully I did not experience any travel delays\ndue to the conflict or the continued government shutdowns in the United States. From what I could gather, the\nattendance seemed higher than in Atlanta and I have to attribute some of that to people\u2019s comfort with\ntravelling to Europe.<\/p>\n\n
<\/p>\n\n
I started the week with my favorite activity, the Maintainer Summit. I knew going in that the summit was sold out\nthis year, and it sure felt like it. Every session was packed, there were many hallway conversations happening, and\nthere was generally a great vibe in the air. Folks were excited to see each other, talk about their projects, and\nstart doing some face-to-face collaboration. As in the previous edition, the conference committee really listened\nto the feedback and we once again had hot meals for lunch and more unconference sessions (although it\u2019s always a\nsort of mad scramble to get the sessions in and voted on before the afternoon).<\/p>\n\n
After the keynotes, I attended the Ask the Experts: Kubernetes Steering Committee<\/a> session. I\u2019ve been\nkeenly curious about the steering committee and these sessions really help to cement my understanding and interest.\nAs might be expected there were many questions for the representatives about the use of AI technologies in the\nKubernetes development process. I was encouraged by the responses to the questions about AI, in general protecting the humans is\nof paramount priority. To support this, there must always be a human in the chain of responsibility when evaluating\nissues and pull requests. Further, there was acknowledgement of more and more projects being inundated with generative\nLLM contributions. These contributions don\u2019t just come in the form of code, they also appear as comments and desciptions\nin the various communications channels. There is broad support for any human who feels that they are being\noverwhelmed by generative content. I was happy to see such a strong focus on the human element.<\/p>\n\n I have been a contributor to the Cluster API project for many years now, mostly as the maintainer for the Cluster\nAutoscaler and Karpenter providers, so it was a natural fit that I would attend the Cluster API Project Meeting<\/a>\nnext. This was a great discussion with the other maintainers and community members where we talked a lot about\nCI and a kubetest2 deployer for Cluster API, and also about the low level mechanics of node joining and how that might\nbecome more structured in the future. We talked about what a \u201cconformance\u201d with Cluster API would mean for various\nproviders and how that relates to the API contracts that the project defines for provider implementers. All in all this\nwas a great discussion and I always love getting a chance to hang out with the other Cluster API maintainers.<\/p>\n\n Next up on my schedule, after lunch, were the unconference sessions. There was a little confusion about these sessions\nas we vote on them the day of the summit and then the conference committee has to plan where and when they will be.<\/p>\n\n After a few hiccups, I had found a popular session on How Should Maintainers Navigate (and Review) AI-based PRs?<\/a>.\nThis session had a lot of great back and forth between the attendees about how we handle the flood of AI-based\ncontributions that are hitting CNCF projects. There were many people who shared stories about how their projects are being\naffected and it is clear that the focus of contributions is not even across the CNCF landscape. Some of the highlights\nfrom this session were:<\/p>\n The discussion was very lively and I was happy to see that many of the points made by the steering committee were being\nreinforced organically by the community. Many people are still learning how to navigate this new world of software\ndevelopment. Some people have had great success and others have experienced terrible failures, but it is clear that as\na community we want to work towards a world where these tools can be used safely and consciously by contributors.<\/p>\n\n As I mentioned previously, I have been maintaining the Cluster API provider for the Cluster Autoscaler for several years now.\nSo I was not going to miss Jack and Kuba\u2019s session on Cluster Autoscaler Evolution<\/a>. In this session they described\nhow the Cluster Autoscaler is going to transform to a code model that more closely aligns with how Karpenter is distributed,\nnamely as a library. I think this is an exciting step forward for the autoscaling community as it will allow the maintainers\nto separate the concerns of specific providers from the core behavior. In addition to the library migration there are also\nseveral new features that will be coming to the autoscaler that I think will be eagerly awaited by the community, for one\nthe ability to defragement clusters. More on these features to come in the months ahead.<\/p>\n\n With my SIG Cloud Provider hat on, I have been following the Node Lifecycle Working Group\u2019s efforts since it began last year.\nWhile I\u2019m not yet convinced there is much work needed to be done by the SIG, I do think it\u2019s important to keep touch on\nthis work as there might be ways that the SIG can help support the new interactions being proposed. To support that, I\nwent to the unconference session Node Lifecycle State Needs a Real API<\/a>, which was a good discussion from the\nmaintainers of the working group about how we might identify the states needed to improve lifecycle awareness for nodes. It\u2019s\na complex issue and I have a feel it will be solved incrementally by addressing the sub-problems, such as eviction, first.<\/p>\n\n To wrap up the \u201cbusiness\u201d part of my maintainer summit day (as opposed to the after hours party), I attended the SIG Autoscaling\nmeetup. I was a little late to this session as I had gotten into a deep hallway track discussion about improved ignition\nintegration in Cluster API. Regardless, I arrived in time to hear the continued discussion about the new architecture for the\nautoscaler. This initiative is going to be big for this year and I expect that by the next summit in Salt Lake City much of the\ninitial work will be complete. Another big topic of discussion for the autoscaling community is the decoupling of the scheduler\nfrom the core of the Cluster Autoscaler and Karpenter projects. There is a new API being developed to help with the workload and\ntopology aware scheduling that will help this effort and I am very curious to see how it develops.<\/p>\n\n After the end keynotes, we all gathered for the maintainer summit group photo<\/a> and then on to the socializing with refreshements!\nThe wandering photographers managed to catch Justin and I deep in a conversation about AI workflows and what the future might\nhold.<\/p>\n\n Coming close on the heels of the Dynamic Resource Allocation (DRA) designs that have helped to improve the state\nof advanced hardware utilization in Kubernetes, comes the next big design work: workload aware scheduling. I am thankful to\nJohn Belamaric and Wojciech Tyczynski from Google who organized this design summit where many SIG tech leads and\nchairs, as well as interested parties, were invited to participate in architecting the future of Kubernetes scheduling.\nThis design summit was focused on the myriad problems that need to be addressed so that we can improve the story\naround workload awareness during scheduling.<\/p>\n\n Workload aware scheduling speaks to the notion that there are workloads which have greater scheduling constraints than Kubernetes currently\nsupport today. Think about applications where network topology and rack location have an impact on the results. For example, the\nmachine learning workloads that we see today can often request to have hardware that shares a network segment or in the most\ndemanding cases might need multiple racks of hardware physically located near each other. The design summit was an opportunity to\nhave people in one place to discuss the various issues around how the Kubernetes community can deliver these features for users.<\/p>\n\n The day was separted into a few sessions and was organized in a very unconference fashion. There were two general themes that emerged\nfrom the topics: scheduling and autoscaling. It was difficult for me to pick which tracks I wanted to participate with since I am\nrepresenting SIG Cloud Provider to see where we might help with lower level provider interactions, but I also want to keep track of what \nis happening with the autoscaler as I am keenly interested in ensuring that the Cluster API intergrations are as full featured as possible.\nIn the end, I chose to participate in the scheduling tracks as there were many autoscaling experts in the room and I generally was curious to\nsee what solutions they agreed on. I was rewarded with some deep discussions around the mechanics of how workload aware scheduling will\nneed to work from the hardware pespective. This ended up being very fruitful for me as I walked away with some clear ideas about how\nSIG Cloud Provider might support activities where scheduling plugins will need to make calls to the underlying infrastructure provider\nto learn about the hardware configurations and topologies.<\/p>\n\n For anyone interested in this exciting new area of development, I would start by reviewing the DRA related mechanisms that exist in\nKubernetes today. These primitives are inspiring how the future of workload aware scheduling will be architected. Then I would study\nthe workload aware related KEPs that are currently under review<\/a>.<\/p>\n\n Lastly, I am grateful for the opportunity to participate in this design summit. Although I don\u2019t think I had much to contribute, I\ncertainly learned a great deal and will hopefully be able to support the effort through SIG Cloud Provider. I\u2019ve heard that quote\nabout \u201cif you are the smartest person in the room, find a new room\u201d, and I felt humbled by the assembled brain power at the summit.\nSome of the brightest and sharpest minds in the Kubernetes community were there and it was inspiring to watch the thoughtful discussions\nthat arose.<\/p>\n\n After two solid days of work already, KubeCon proper starts. I briefly cruised the keynotes and the early talks, but my mind was focused\non the two big activities I had for day 1: the Kubernetes Contribution 101<\/a> session, and the panel\nFrom Static Tokens to Attestation: The Evolution of Secure Node Joining<\/a>. I was a participant in both activities and I was quite\nexcited for the opportunities.<\/p>\n\n The Community Hub is one of my favorite parts of KubeCon and when the call went out for SIG chairs and tech leads to participate in the\nContribution 101 session I jumped at the chance. It was a nearly two hour session where we had a presentation about the mechanics of\ncontribution and the landscape of the CNCF projects, and then a question and answer portion where the SIG leads got to interact with\nthe audience. It was truly inspiring to see so many people interested in contributing and asking thoughtful questions about how to get\ninvolved. Whenever I have time, I will always participate in these sessions as I love helping new folks get a boost into open source. Passing\non the open source values and ethics is a large part of what I do these days and I want to ensure that we have a healthy community for\nfuture generations.<\/p>\n\n After the 101 session I had to find the panel where I was a particpant, unfortunately the room was on the opposite end of the convention\ncenter and I had to make haste. Thankfully, I made it with time to spare. The panel went great and we had about 150 people in the room to\nhear us talk about a possible future for secure booting and attestation in Kubernetes. In some respects this is new territory for the\nKubernetes community to tackle, although there are bespoke implementations of this style of booting, we would like to develop best practices\nthat the community as a whole can rely on. This will be important if we want to include secure boot activities in projects like kOps and\nCluster API. While there is more work to be done, we had an excellent conversation and got many good ideas from interacting with the audience.\nI\u2019m hopeful that some of the work I\u2019m doing with the Cluster API community to improve ignition support will also help with the workflows\naround attestation.<\/p>\n\n I spent the remainder of my time on day 1 cruising the solutions showcase to see what people were talking about with respect to the product\nside of Kubernetes. The solutions showcase was a good time and there was plenty of room and natural light penetrating the room, making it feel\nmuch better to walk around and get lost amongst the technology. As always, LEGO raffles were huge. I also noted the return of the curling\narena.<\/p>\n\n In many ways, day 2 was a repeat of day 1 for me. I had plans to participate in the Kubernetes Meet + Greet<\/a> and then join the\nHow Will Customized Kubernetes Distributions Work for You? A Discussion on Options and Use Cases<\/a> panel. It should go\nwithout saying that I love the meet and greet. It\u2019s been a high point for me for several KubeCons now and I volunteered to work the\nfirst hour as a greeter, and then would join the second hour in my SIG Cloud Provider capacity to talk with attendees.<\/p>\n\n The meet and greet went great, I was able to meet many new folks and help them to find the communities where they could learn and connect\nwith others. After my official duties had ended, I got a good slice of time to talk with people about SIG Cloud Provider and how they could\nget involved. One inspiring discussion that came out of this was with a gentleman who had done documentation work across three languages!\nHe was connected with developer communities in Vietnam and was curious how he could connect those communities with the wider Kubernetes\ncommunity. It was great to talk about how Vietnamese cloud providers will be able to join our efforts and really how they can gain\nthe benefits of the common cloud provider framework we have developed. It made me feel good to know that the work we are doing in the\nopen source can truly reach all communities so that they can join the great activity that is happening around Kubernetes.<\/p>\n\n I had to run at the end of the meet and greet to make the second panel I was doing for this KubeCon. I made it back to the panel room with a\nlittle time to spare, but as it turned out the panel before ours (which was on Node Lifecycle APIs) was packed to the rafters and we had to wait\noutside for the room to empty.<\/p>\n\n The panel went off well and we had about 150 people show up to hear us talk about the idea of Kubernetes distributions. I wasn\u2019t sure\nwhat to expect when we proposed this panel. SIG Cloud Provider has been interested in this notion to help us achieve some testing goals, but\nalso to work towards the future where there is a clear method for cloud provider specific bits to be included with a Kubernetes installation.\nWhether that installation happens from kOps, Cluster API, or some other tooling, we would like there to be a common set of guides to follow.\nI was touched by how many people approached me afterwards to thank the SIG for diving in to this topic. We\u2019ll see how things progress.<\/p>\n\n In a similar fashion as day 1, I spent some time at the end of the day in the solutions showcase checking out the project pavilion and connecting\nwith friends at different companies who were working booth duty.<\/p>\n\n By Thursday my tanks were running on near empty, but I wanted to get around to the project pavilion again to check out the projects I was less\nfamiliar with, and I was rewarded richly. I spent time talking with my colleague Thilo at the Flatcar Linux booth. We are attempting to improve\nthe state of ignition in Cluster API and I\u2019m hopeful that we\u2019ve made some solid designs for work that we can do this year. I also spent time talking\nwith the Bootc project team as well. Bootc<\/a> is a really cool project that unlocks a great deal of potential for managing and upgrading\nostree style operating system images. I\u2019m sure it can do so much more than that, but the demo that my colleagues from Red Hat gave showed how\nyou could perform rolling upgrades and downgrades to an application embedded as part of an ostree image. I am absolutely planning to setup a\nhome lab for playing around with bootc, especially since I think it will help with the ignition\/Cluster API work I\u2019d like to do.<\/p>\n\n I would be neglectful if I didn\u2019t mention the presence of AI at KubeCon. There were plenty of talks and demonstrations with people showing off\nhow they are using AI to build value and also integrate AI into their products. Additionally there was no shortage of talks about how AI\nis affecting, and will continue to influence, the software development process. I found the discussion good and the amount of AI related talks\nonly a little oppressive. One thing I noted that is increasing from the hallway track perspective is that many people are getting tired of\nseeing AI related talks and want to see more technical Kubernetes information. I saw several non-AI sessions that were packed to capacity,\nand my informal discussions with people seemed to indicate a weariness of AI and also a desire to find spaces where AI was not being\ndiscussed. Hopefully this is a sign that the community is large enough that we need more equal represenatation of ideas at KubeCon. AI has\nmade its mark and will continue to evolve, but it is not the Ur-solution for all problems.<\/p>\n\n KubeCon Amsterdam was a tremendous success for me. I had an excellent time connecting with friends and peers from across the industry\nand got to participate in some amazing discussions. I am optimistic about the future of Kubernetes and I look forward to how the\ncommunity will continue to grow and evolve.<\/p>\n\n I am hesitant about the continued usage of AI in our software development processes. I can see the benefits but I also see the harm that\nit can do to the people involved in the process. I think the most important thing for us to remember is that the people who make up this\ncommunity are the most important element, and we should ensure that regardless of the technological changes happening we continue to \nrespect and protect the community members.<\/p>\n\n In brief, here are some thoughts I had:<\/p>\n\n Whelp, that\u2019s about it for my thoughts on this retrospective. I hope I can continue to attend KubeCons and be part of this community.\nIt brings me great joy and satisfaction to know that what we are building, in the open, can help make the world a better place. It seems\nchallenging to remember this given the state of the world these days, but I count myself as an eternal optimist in this respect. If you\nmade it this far, thank you, be safe out there, and as always happy hacking!<\/p>\n\n Well, it\u2019s been about a year since I updated this blog, so why not get back into things by giving my\nretrospective on this fall\u2019s KubeCon North America. TL;DR fewer people, slightly less AI hype, and\nloads of good conversations.<\/p>\n\n KubeCon North America for 2025 was hosted in Atlanta Georgia in the United States. The offical \u201cKubeCon\u201d\nwas on the 11th through the 13th of November, with the CNCF co-located events happening on Monday the\n10th, and the Kubernetes Maintainer Summit happening on Sunday the 9th. I was lucky enough to travel to\nAtlanta for all the events, but the start of my journey was slightly delayed due to the government shutdown\nin the United States. It\u2019s worth mentioning the political activity in the United States, without going into\ntoo much detail, as I believe the current political climate contributed to my perception of a smaller population\nat this KubeCon.<\/p>\n\n But, even though my flight was delayed by 6 hours, I was able to finally make it to Atlanta. I heard stories\nfrom many friends and colleagues who had flights delayed, and in some cases cancelled, which led to a fun situation\nwhere most of us were asking each other \u201chow long was your delay?\u201d as we met at the conference.<\/p>\n\n As is tradition, maintainer summit is my favorite part of the conference. This year, we started with the summit\noccurring before any other event. There was a small gathering at the conference hall and we had a day of\nconversations, presentations, and unconference sessions; this year including a hot meal for lunch! (thank you con team <3)<\/p>\n\n We started with the keynotes and getting warmed up for the day, it\u2019s always nice starting out with some laughs\nand looking around the room to see who you might recognize. As I noted, the attendance seemed a little lower\nthan previous summits and some of that was due to the travel challenges, and the rest I believe was due to folks\nnot wanting to engage with the United States customs and border control.<\/p>\n\n I started my summit by attending the TAG Workshop<\/a> hosted by Karena Angell, Mario Fahlandt, Brandt Keller,\nand Dylan Page. TAG stands for \u201cTechnical Advisory Groups\u201d and this was my first experience learning how these groups\noperate and what function they serve in the community. I was glad to learn that they help with cross-project efforts\nand in areas where greater coordination is needed for initiatives that will affect several technology groups. A large\npart of the reason I wanted to learn more about the TAGs is that the testing work I am interested in doing<\/a>\nis going to involve some level of standardizing around how Kubernetes is deployed for different cloud providers, something\nwe have been calling \u201cdistributions\u201d in SIG Cloud Provider.<\/p>\n\n As happens at these events, the discussion I was having about kubernetes distributions continued past the end time for\nthe TAG Workshop and I ended up spending my next session in the hallway track<\/em> talking with folks about the idea. Basically,\nit would be very convenient for cloud provider testing to have the notion of a distribution<\/em> of kubernetes. This would mean\nincluding a reference topology (eg 3 control plane nodes instead of 1, etc) and also including provider-specific components\ndepending on the distribution. For example, on OpenStack, the kubernetes distribution would include the cloud controller manager\nfor OpenStack, plus any other storage or networking components required for that platform. This would help us in arriving\nat a destination where tests could more easily select the platform and also the components that need testing. In the end\nwe will have provider agnostic tests that can operate on any provider, but which will also exercise provider-specific behavior\nthrough provider interfaces.<\/p>\n\n After lunch, I went to some of the unconference sessions starting with\nBetter Together, Strengthening Inter-Project Collaboration & Developer Experience Across the CNCF Ecosystem<\/a>\nproposed by Yacine Kheddache and Colin Griffin. This was a fun session where we talked about how to better share\ninformation in the CNCF community, especially for the purposes of helping increase cross-project collaboration and knowledge.\nAs with many unconference sessions, the discussion really got going once the time was almost out, but I had a revelation while\nparticipating in the discussion. Essentially, we could use more project manager community members. This is something I have\nstruggled with in the past, but it was purely based on people reaching out to me for mentorship as project managers. I never\nhad a good answer for this style of collaboration in open source projects, but in this Kubernetes community I am now seeing\na clear place for these roles. In the future I am going to guide project managers to become more involved in the social glue<\/em>\nthat holds our community together. I think there is a strong place for contribution in the form of people who can go between\nprojects to help advocate for projects needs in differing venues. Perhaps another blog post topic for the future ;)<\/em><\/p>\n\n The last session I attended was the one on Making the Kubernetes CI\/Infra better<\/a>. Now, this wasn\u2019t technically the\nlast session of the day, but the discussion I got into towards the end kept going into the hallway track, and by the time we\nwere done it was time for the group picture. This session was great though, especially given my desire to chase the idea of Kubernetes\ndistributions. I learned a lot in this session and came away with a new excitement about building a Cluster API deployer for\nkubetest2<\/a>. We\u2019ll see where it goes, but I\u2019m optimistic about the future of Kubernetes cloud provider testing.<\/p>\n\n After a day of visiting with colleagues and talking about the future of Kubernetes we adjourned for some much needed relaxation.<\/p>\n\n It\u2019s going to be a big week, so I need to start with a solid breakfast. We don\u2019t have Waffle House in my state (Michigan), and\nit is a national institution so I had to visit. (I actually went almost every day XD)<\/em>\n On Monday, I had the pleasure of visiting OpenShift Commons<\/a> as an attendee instead of a speaker or employee, which\nwas a change from previous years. I love the Commons and as a Red Hat event I always feel a little like a celebrity when\nI visit. I was able to spend some face time with colleagues and even got to talk with a customer or two. It is very gratifying\nto hear about our customers\u2019 journeys and how our efforts become solutions for them.<\/p>\n\n After spending the morning at Commons, I returned to the convention center to watch my teammate Mansi Kulkarni give\na talk on Windows Container Monitoring Demystified: OpenTelemetry in Action<\/a> with her peer Ritika Gupta. As\nI don\u2019t normally work on this area of Kubernetes, it was interesting to hear how Windows containers work and also\nhow they are monitored by users. It\u2019s a wild world combining container technology with the Windows kernel.<\/p>\n\n I didn\u2019t have a ton going on Monday aside from catching up with folks, so I spent some time reading code and planning\nfor KubeCon proper.<\/p>\n\n After the keynotes, I availed myself of a walk through the exhibitor hall and then found some talks to watch. I also\nstopped many times in the hallway track to catch up with folks I had not seen in several months.<\/p>\n\n One of the big talks on Tuesday was Corey Quinn\u2019s The Myth of Portability: Why Your Cloud Native App Is Married To Your Provider<\/a>.\nI was only a little familiar with Corey\u2019s work and I was not at all ready for his presentation style. This talk was well polished, and\nwell delivered. Corey has a unique style that trends more towards comedy than analysis. His message was astute though, about the\nintracacies and challenges of delivering applications in hybrid environments and what it means to make an application truly portable\nacross clouds. I found his analysis of the problem to be spot on, his solutions left me wanting more though, and his delivery was downright\nmean-spirited. While he made good points, I couldn\u2019t help but feel insulted as he emphasized again and again how the work of myself and\nmy peers was \u201cshit\u201d.<\/p>\n\n Thankfully, after the mean-spirited pillory of the previous talk, I was delighted to see Taylor Dolezal and Erica Hughberg\u2019s talk\nThe Missing Manual for Open Source Community Sustainability<\/a>. I found this talk energizing and informative about how we\nbuild more sustainable processes into our communities. I really enjoyed how Taylor and Erica broke down the personas within software\ncommunities, and then provided techniques for engaging with those people. I left with a full page of notes from this session.<\/p>\n\n The last session I attended on Tuesday was Beyond the Code: How the Kubernetes Steering Committee Tackles the Hard, Non-Technical Problems<\/a>\nhosted by Antonio Ojea, Benjamin Elder, and Maciej Szulik. I have been curious about the steering committee and how they work; this\nsession delivered exactly what I desired. I learned a great deal about how the committee is structured in relation to the SIGs and WGs,\nand also how they operate. It was nice to hear stories from the current committee members about how they ran for election and what the\nexperience has been like for them. Also, very cool to hear how the kubernetes community keeps itself healthy and on-track.<\/p>\n\n Wednesday was a big day for me as I was part of a talk, so I spent the morning preparing. At 11:30am it was time for us to present\nMaximizing Global Potential: Cost-Optimized, High-Availability Workloads Across Regions<\/a>. I joined Praseeda Sathaye and\nJingkang Jiang, with shoutouts to Wei Jiang, to present this talk and we had an absolute blast. We talked about how kubernetes can\nbe deployed globally across regions and providers to deliver highly available infrastructure. We demonstrated how the Karmada,\nCluster API, and Karpenter projects can be utilized to build a single multi-cluster workload pipeline. We had about 60-70 people in the room and got\nsome good questions.<\/p>\n\n After our talk, I quickly moved to the SIG\/WG Meet & Greet<\/a>. The meet and greet is another of my favorite activities at\nKubeCon. It\u2019s a great chance to hang out with maintainers and learn about kubernetes and the community, and to pick people\u2019s\nbrains about what is next, or how to get involved. I absolutely recommend it to anyone who wants to learn more about the\nmaintainer community.<\/p>\n\n I was talking with Josh Berkus at the end of the meet and greet and we both noted how the line for the puppy petting event\nwas very long and also right outside the meet and greet. This could perhaps be a good technique for bringing more folks to the meet\nand greet next time. Just put the puppy pit at the back of the meet and greet. XD<\/p>\n\n Next it was on to see my colleague Jose Valdes co-present with Mark Rosetti on the Kubernetes SIG Windows Updates<\/a>. As I\nnoted earlier, I don\u2019t normally work on Windows (although I did in a previous life), but I learned some cool stuff in this presentation\nand I got to support my teammate. I find it interesting to learn how Windows is able to meet the OCI standard through its various\nprocess APIs. I\u2019m not sure I\u2019m ready to return to that world (I\u2019m not), but I enjoyed learning more about this corner of the\nkubernetes ecosystem.<\/p>\n\n After all that, I still had some gas left in the tanks and I was eagerly waiting for Justin Santa Barbara and Ciprian Hacman\u2019s talk\nThe Next Decoupling: From Monolithic Cluster, To Control-Plane With Nodes<\/a>. In this talk, Justin and Ciprian were\ndiscussing some experimentation they would like to do in kOps<\/a> to add more support for Cluster API and Karpenter. I find these\nideas to be exciting and a good path for improving our testing efforts across platforms. It filled my head with more\nthoughts about extending kubetest2 and building a proof of concept on top of their work. Also, they produced a logo for Karpenter\nthat I absolutely adore, and I want to make it the Karpenter Cluster API logo:<\/p>\n\n wow, what a Wednesday!<\/p>\n\n By Thursday I was nearly completely wiped out, but I was part of a panel that would be the last session of the day. So, I pushed forward\nand made some connections. I spent most of my day talking with various colleagues about the work we are doing and what we would like\nto do in the next 6-12 months.<\/p>\n\n Then, at the end of the day, I was delighted to join my fellow SIG Cloud Provider co-chair Bridget Kromhout, as well Joel Speed, Walter\nFender, and Jesse Butler to have a panel about SIG Cloud Provider Deep Dive: Expanding Our Mission<\/a>. I had a great time and I\u2019m\nfairly sure the other speakers did as well. We had a nice chance to talk about how the SIG is working to create cross-platform building\nblocks for the future of kubernetes. We had a nice attendence for our event and a good discussion among the panelists. I\u2019m optimistic about\nthe future, and it seemed like our discussion and energy permeated into the audience with several nice comments directed towards the SIG at\nthe end.<\/p>\n\n This KubeCon seemed smaller than years past. I can only assume this was due to travel and the behavior of the government of the\nUnited States. I was nervous to travel, especially given the shutdown and delays, but I am glad I made it. I love seeing my\nfriends in the community and I generally had a positive experience in Atlanta. I also walked away with many new ideas and that\nfamiliar sense of excitment that percolates when I\u2019ve got plans a\u2019brewing.<\/p>\n\n Some thoughts I had:<\/p>\n That\u2019s about it from me. Another KubeCon in the books. Hopefully this small report has helped to give one window into KubeCon.\nI hope to make to Amsterdam, if you see me come say hi (and don\u2019t be surprised if I give a quizical look at first). I\u2019ll try\nto wear my fedora again, it seemed to be a good way to find me lol. As always, stay safe out there and happy hacking!<\/p>\n\n I attended KubeCon North America 2024 in Salt Lake City last week and this is my retrospective on the trip.<\/p>\n\n KubeCon North America for 2024 was hosted in Salt Lake City from November 13th through the 15th, with three days of events before the conference. In addition to KubeCon, I attended the Cloud Native Rejekts on Sunday the 10th, the Kubernetes Contributor Summit on Monday the 11th, and OpenShift Commons on Tuesday the 12th. The weather was mostly nice, with a little rain on Tuesday, with temperatures generally cool in the mid 30s to high 40s Fahrenheit. Salt Lake City is easy to get around, it has generally large blocks and roads in the downtown area, there is also public transportation, and an amazing view of the mountains from just about everywhere.<\/p>\n\n Cloud Native Rejekts is a conference that bills itself as \u201c\u2026 the b-side conference giving a second chance to the many wonderful, but rejected, talks leading into KubeCon + CloudNativeCon\u201d. It is usually a great place to see high quality talks in a smaller setting than KubeCon, and an opportunity to meet up with other people to talk about Kubernetes before the main event<\/em>.<\/p>\n\n This year, I was presenting a talk with colleague David Morrison from the Applied Computing Research Labs titled \u201cKarpenter and Cluster Autoscaler: A data-driven comparison\u201d. We had about 20-25 people in the audience, and it went fairly well considering we had some issues with latency on the slide display.<\/p>\n\n On Sunday, there were probably around 200 people in attendance at Rejekts. There were 2 presentation areas: the main theater, and the flex room. Most talks saw people filling the rooms and I noted several with crowds standing in the hall to catch the topics (the eBPF talks were popular). I met several old friends during the social time for Rejekts and it was a great \u201cpre-game\u201d for KubeCon. If you are ever coming to a KubeCon and have the inclination and opportunity to arrive early, Cloud Native Rejekts is a free event and the talks are focused on technical topics, I recommend checking it out at least once.<\/p>\n\n The contributor summit is my favorite part of KubeCon. The amount of high-bandwidth conversations and learning that I do during the summit is unparalleled for me at any other Kubernetes event. This year was no different. I\u2019m not sure on the total attendance numbers for the contributor summit, but I would not be surprised if there were a few hundred people there throughout the day. We had several general sessions, including an awards ceremony, and breakout rooms with pre-planned and unconference topics.<\/p>\n\n I felt that one of the big topics for this summit was getting to know and understand the steering committee. We had a good panel session with the committee and it generally seemed like they wanted the contributor community to understand what the steering committee does, and how we can lift more voices to join the committee. I found this to be a good topic of self-awareness for the Kubernetes contributor community, and I continue to be impressed at the thoughtfulness of this community in terms of attempting to keep itself healthy, active, and inclusive.<\/p>\n\n There were 2 talks I attended during the summit that I would like to call attention to:<\/p>\n\n I found the talk on CRDs interesting because for many years now the Kubernetes community has been attempting to address several issues around CRDs (versioning and migrating to name two) and this talk was moving the ball forward on those issues. I also found the talk on testing to be interesting because the author is proposing a test framework that should be built specifically for Kubernetes to address the specific needs of test writers. There seems to be a good opportunity to help push the Kubernetes tests towards a more unified approach, and bring in more contributors who might want to join the testing efforts.<\/p>\n\n Aside from the talks, a big part of attending the contributor summit are the project meetings. I am an active contributor to the Cluster API project and I attended their project update session. This year was not as well-attended as previous years with only around 10-20 people in attendance, but we had a great discussion about the future of the project. Some of the topics we covered during the discussion were the in-place upgrades proposal and status, and etcd resiliency in Cluster API clusters.<\/p>\n\n OpenShift Commons is a Red Hat sponsored event where we talk about all things Red Hat and OpenShift. I volunteered to help with operations and also to be part of the round table discussions representing the OKD community with my peers Amy Marrich and Jaime Magiera.<\/p>\n\n I love attending the OpenShift Commons, not only because I work on OpenShift and it\u2019s a great opportunity to meet with users, customers, and partners, but also because it\u2019s a great chance for me to spend some time with other Red Hatters. It was a really nice event and it seemed like we were nearly packed to capacity. I\u2019m not sure how many people were there but it had to be a few hundred.<\/p>\n\n The round table discussions were interesting and I ended up talking with a few folks about how using OKD (the community supported version of OpenShift) could help their operations team in sketching out<\/em> features they would like to see in OpenShift someday. The idea being that if you would like to see a feature in OpenShift, and you have some technical understanding around OpenShift and the feature, then you could use OKD to add the feature and demonstrate a proof of concept. This seemed to resonate with the people I talked with, although we all admitted that there is a significant engineering resource demand to create these types of demonstrations.<\/p>\n\n Commons also had one of the best pieces of OpenShift swag I have ever had the pleasure of snagging: OpenShift keycaps!<\/p>\n\n Wednesday brought the official start of KubeCon. I followed the herd (we were told attendance reached 9,200 people this year) to the first day keynotes and with that, KubeCon had begun. Two of the big themes for this KubeCon were AI, and security, with the first two days being dedicated to those topics respectively. The first day keynotes seemed well attended and there was a buzz in the air that was familiar. Immediately after the keynotes was the stampede to the exhibit hall.<\/p>\n\n The exhibitor hall was fun, as usual, with some special highlights being the pickleball court and the inflatable curling. It didn\u2019t feel over-crowded or empty, and the times I visited there were plenty of people walking around. The project pavilion was also in the exhibitor hall and I ended up doing an unscheduled impromptu demonstration of the Karpenter Cluster API project, which was fun but also chaotic. This demonstration led to several hallway track<\/em> conversations on Wednesday about Karpenter and Cluster API. While AI and security were the conference themes, one of my themes for the week was definitely Karpenter as I got into many more conversations about it than I anticipated.<\/p>\n\n I saw a bunch of talks on Wednesday, and I would like to call attention to a couple that I think are worth watching when they are posted:<\/p>\n\n The first talk on heterogeneous compute resources gave a window into the future of exposing more details about processors to help make scheduling and processing more efficient. Alexander gave a nice overview of how different workloads can be adversely affected by some processor architectures. In a world where nanoseconds can make a difference, this is a great talk to understand how to identify and minimize those bottlenecks.<\/p>\n\n The second talk was a deep breakdown of how networking metrics can be used to identify performance limiters and speed bumps in your infrastructure. Understanding networking failures is difficult enough without all the layers that cloud native infrastructures add. Being able to see real world uses of the metrics alongside the methodology for understanding the implications of those metrics was enlightening for me.<\/p>\n\n Near the end of the day, I ended up getting into a deep discussion with some friends from SIG Storage (shoutouts to Hemant, Jan, and Michelle). They had been chatting all day about a storage issue related to CSI drivers and the Cluster Autoscaler. It was an interesting discussion and I think after about an hour or two we had made some progress on possible solutions, now if only we could find the time to work on them!<\/p>\n\n Wednesday evening was also the \u201cBooth Crawl\u201d at the exhibitor hall, but as I had dinner plans with my colleagues from Red Hat, I skipped out for the evening.<\/p>\n\n Day 2, I\u2019m exhausted but driven forward by excitement and the goal of delivering a talk on Friday.<\/p>\n\n For the first time in my KubeCon history, I attended a workshop on the DEI track. I saw this title in the schedule and, given my interest in building healthy open source communities, I felt that I had to attend:<\/p>\n\n I was rewarded with an hour of discussions and group activities where I got to hear about some common issues related to inclusion, and then got to spend time talking with people about their experiences. I had a good time and learned a little more about what I can do to help build more inclusive communities, and what to look for when things aren\u2019t quite going right.<\/p>\n\n I do a lot of work with the Cluster Autoscaler and Karpenter projects, so I was keenly interested to see the SIG Autoscaling update, delivered by my friend from the Cluster API community, Jack Francis. It was a nice overview covering all the projects that the SIG sponsors, how users can get involved, and some crystal ball gazing about what is coming next for the SIG. If you are interested in node or pod autoscaling, definitely watch the recording.<\/p>\n\n Something I love being a part of at KubeCon is the SIG Meet n\u2019 Greet. It is an occasion for the Kubernetes SIGs (Special Interest Groups) to make some space and do a little self-promotion. I represented SIG Cloud Provider and had a number of interesting discussions with people who are interested in what the SIG does, and also how they can build cloud controllers for their own infrastructure offerings. I also had a few people approach me about Karpenter related topics, which was nice.<\/p>\n\n My friend and teammate Joel Speed also had a talk on Thursday about CEL validation budgets. If you are using CEL with your Kubernetes API designs, I think it\u2019s worth watching the recording to learn the deep details about how validation budgets are calculated.<\/p>\n\n I ended my day at the conference by attending a talk on the OpenCost project. I am keenly interested in exploring how the Cluster API project could expose information about instance pricing. I\u2019m not quite sure what the best way to do this is yet, but I have been wanting to explore OpenCost to see if it might be appropriate for Cluster API. I\u2019m still not sure, but the talk I watched did help me understand some basics about OpenCost. It wasn\u2019t quite what I was expecting, but I found it interesting as a primer.<\/p>\n\n Last day of KubeCon, for now.<\/p>\n\n I didn\u2019t have a lot on my agenda for Friday aside from co-presenting the SIG Cloud Provider maintainer track talk. But, I was happily surprised to see this talk about flaky tests and continuous integration. It gave me a better window into how the Kubernetes testing infrastructure is configured and deployed. I am keenly interested in this because I would like to improve the state of testing for cloud controllers. And, as luck would have it, this talk about flaky CI was happening a few slots before our talk related to testing. I highly recommend watching the recording if you have an interest in Kubernetes continuous integration testing.<\/p>\n\n Fridays at KubeCon are always tough for me as I am usually exhausted but also want to catch up with people before we all leave. This year was no different. I spent much of my time walking around and having discussions with people (shoutout to Kevin on our talks of what will disrupt Kubernetes and the state of homelab clusters). But, as the day, and con, were winding down it was time to deliver our talk for SIG Cloud Provider:<\/p>\n\n I\u2019m happy and proud to say that the talk went well despite the standard technical shenanigans at the beginning. I also want to say a big thank you to Bridget as well. I have had the pleasure of co-presenting with Bridget a few times now and she is a talented and amazing person to be on stage with. I was humbled to hear the audience\u2019s reactions to our presentation and I\u2019m so happy that people enjoyed themselves and appreciated our delivery. Looking forward to having another opportunity like this in the future.<\/p>\n\n And with that, I started to make my way out of the building for the last time at this KubeCon. I did see a few people on the way out, and got my last hugs and well-wishes in. It was an amazing and exhausting experience as always, and I\u2019m hopeful I can attend in London.<\/p>\n\n KubeCon is a bustling place filled with ideas and excitement, and this edition was no different. Here are some of my unvarnished thoughts about my experiences:<\/p>\n\n So, that\u2019s it, another KubeCon in the books. I hope this retrospective gave you a taste of what the excitement is all about. And I sincerely hope that if you find this exciting, that you also may attend some day. I look forward to seeing you out there on the road, and as always, stay safe out there, and happy hacking =)<\/p>\n\n","pubDate":"Tue, 19 Nov 2024 00:00:00 +0000","link":"https:\/\/notes.elmiko.dev\/2024\/11\/19\/kubecon-na-2024-retrospective.html","guid":"https:\/\/notes.elmiko.dev\/2024\/11\/19\/kubecon-na-2024-retrospective.html"},{"title":"Developing the Karpenter Cluster API Provider","description":" Since October 2023 I\u2019ve been working with the Kubernetes Cluster API<\/a> community\nto develop a native Karpenter<\/a> provider so that we can explore the behavior\nof these projects together. Karpenter is an exciting node auto-provisioner that has features\nfor configurable cluster consolidation and deep cloud inventory awareness, and Cluster API is\na declarative infrastructure API for Kubernetes with coverage on nearly 2 dozen providers.\nIf these projects can work well together, it would give the community an excellent way to run\nKarpenter on many cloud providers. As of last week, we have reached the minimally\nviable implementation for a proof-of-concept, and we are in the\nprocess of donating the repository<\/a> to the Kubernetes SIGs community for wider\nexperimentation and development.<\/p>\n\n Although we have reached a nice milestone for the project, there is still much work to do\nas we attempt to reach feature parity with the native Karpenter implementations. We will also\nneed to learn how best to integrate Karpenter with Cluster API, where the bottlenecks might be,\nand how we can create the best user experience possible.<\/p>\n\n With the first phase of work complete, it\u2019s a nice time to reflect on what we have done and\nhow we got here. This is especially relevant given that the developer community around Karpenter\nis still growing and there are many people interested in implementing providers for other\nplatforms. In this post, I am going to share the process we used to develop the Cluster API\nprovider in hopes that it will help others who are making the same journey.<\/p>\n\n To help us solve problems of architectural constraints, project goals, and user experience options,\nwe started a Karpenter feature group<\/a> in the Cluster API community where we had a regular time\nand space to have and record our discussions and decisions. It took us a few months to arrive at a\ndesign and initial plan for how we would create the proof-of-concept Karpenter. This process was hugely beneficial\nas it gave us ample opportunity to talk through the software constraints that the Cluster API provider\nplaced on this implementation. In specific, the asynchronous nature of infrastructure creation in\nCluster API is slightly at odds with the synchronous nature of Karpenter\u2019s cloud interface.<\/p>\n\n One of the challenges in writing a Karpenter provider for Cluster API is the limitation of needing\nto use the Kubernetes API for making changes to the infrastructure. This means that any time we\nwant to learn about the inventory or status of the infrastructure resources, we need to query the\nKubernetes API and potentially exercise reconciliation loops to ensure that asynchronous behavior\nis captured accurately. This is in stark contrast to infrastructure providers where there is\ndirect access to a metadata service with synchronous responses.<\/p>\n\n In addition to the engineering concerns around designing an integration between Cluster API and\nKarpenter, there is also a necessary focus on how to expose the API features of both projects. Cluster API\nand Karpenter are both provisioning tools built on top of Kubernetes, and this means that they\nhave some overlap in the features they expose. A point of discussion that we spent several meetings\nexploring was the idea of where on the spectrum of \u201cCluster API to Karpenter\u201d does the community want the\nuser experience. Given the nature of Cluster API, I feel this specific design concern will most\nlikely not be an issue for other provider implementers, unless those providers have a user community\nthat expects a deep interaction with the platform APIs.<\/p>\n\n With the plans solidified and the community in consensus about our initial direction, I started to\nbuild a skeleton repository for the project. I did this by copying the Kwok provider<\/a> from\nthe Karpenter repository<\/a> into a new repository, and then building a simple Makefile and\nthe necessary Go files to build the project. At this point I had a basic buildable project and could\nbegin the next step of defining the boundaries for the code changes that would be needed.<\/p>\n\n The Karpenter developers have created a straightforward interface that providers must implement. In\ngeneral it defines functions that provide information about the infrastructure inventory and resources,\nand functions to manage the nodes of the cluster and the resources. It is small enough to reproduce\nhere:<\/p>\n\n The first thing I did after getting the project building was to stub out these functions and have them\nall return the equivalent of a zero response or an error. In this way, anyone looking at the code\ncould easily seen what was implemented and what was not. I also added a README file to the project with\na checklist showing which interfaces were implemented. I then set off on the task of implementing the\nindividual functions.<\/p>\n\n In the case of Cluster API, one of the things I spent a significant amount of time on was figuring out\nhow to translate capacity, geographic, and pricing data from the instance types to the Karpenter API types.\nThis might not be as big a problem on platforms with direct access to a metadata service, but given the\nabstracted nature of Cluster API it posed a challenge in writing some of the functions. I am sure this will\nbe a point of investigation and perhaps expansion in the Cluster API project as we learn more about how\nto expose deep infrastructure metadata.<\/p>\n\n One of the biggest challenges for Cluster API is the implementation of the When learning about how to implement the interface functions and what Karpenter expected from them, I spent\nmuch time exploring the core Karpenter repository<\/a>, but I also studied the way that the\nAWS provider<\/a> and Azure provider<\/a> implemented their cloud provider interface. This study\nhelped me immensely to understand what values would be absolutely required and which might be more supplemental.\nI also used the code of the Kwok provider<\/a> as an example, especially early on in development, but as\nI got further into testing and debugging I found the AWS and Azure providers to be more useful examples.<\/p>\n\n Another very helpful resource was the Karpenter community itself. There are several ways to contact\nand participate with the Karpenter working group<\/a>, and I highly recommend reaching out if you\nhave questions. I was able to connect with several wonderful and helpful people in the Karpenter community\nby asking questions on their Kubernetes Slack channel (#karpenter-dev) and by attending their meetings with\nquestions and announcements on their agenda.<\/p>\n\n Something that I found helpful when sketching out the initial structure for the code of the project was\nconsidering how the AWS and Azure providers were constructed. Looking at their designs from the cloud provider\ninterface down, it was quick to see that they were both following a similar pattern. In specific the\nabstraction between the cloud provider interface functions and the various resource and data provider\nfunctions is worthy of note for designing new implementations.<\/p>\n\n Karpenter requires a few custom resource definitions in order to operate. Notably the NodePool and NodeClaim\ndefinitions, but it will also need some sort of NodeClass implementation for the provider. I found the\npattern for inclusion to be straightforward in the AWS and Azure projects, namely including the YAML manifests\nin a subdirectory of the API code. Following this pattern seemed like the easiest way to keep consistency\nfor developers who might be inspecting the Cluster API provider in the future. To make it even easier, I added\nsome scripting to the makefile to make the generation of those manifests a little easier by rendering them\ndirectly from the vendored dependencies.<\/p>\n\n Checking the custom resource definition manifests in to the code repository makes automating the testing\nmuch easier and also including things like helm charts and other examples. In addition\nto creating the core Karpenter manifests for NodePool and NodeClaim, the repository will also need to contain\nany platform specific manifests, such as the NodeClass implementation.<\/p>\n\n A design question that came up during development was around the lifecycle of Karpenter\u2019s NodePool and NodeClaim\nresources, and how they could be used to carry provider specific information. To be clear, both the NodePool and NodeClaim objects\nare created and reconciled types within the Kubernetes API, and as such you can build other controllers to\ninteract with them. Both the NodePool and NodeClaim are also free to carry provider specific information in the\nform of annotations and labels, as you might expect from any other API object. In my experience, I did not\nhave to implement any specific functions for controlling the lifecycle of the Karpenter resources, they are\nall handled by the core Karpenter controllers.<\/p>\n\n For Cluster API, testing gave me tremendous confidence in the code that we were building. A big advantage\nfor Cluster API in this area is that we could use kubebuilder\u2019s envtest<\/a> package to great effect\nsince most of the platform interactions would happen through Kubernetes resources.<\/p>\n\n Using examples from kubebuilder and some other projects, I was able to quickly configure a test suite that\ncould exercise all of the cloud provider interface functions. This ultimately became a foundation point for\nthe project as it gave me great confidence when bringing the code out of testing and on to a live cluster\nenvironment.<\/p>\n\n Testing should be a core of whatever provider is being built, but depending on the provider, and perhaps the\nmaturity of tooling, it may be more difficult to mock out the infrastructure specific parts of instance\nmanagement. This is something to consider and plan for when building a new provider implementation.<\/p>\n\n After nearly 3 months of design and coding, we achieved the initial proof-of-concept version of the Karpenter\nCluster API provider. There were a few minor bumps to smooth out as integration testing began, but thanks to\nthe unit testing the fixes were quick to implement and before long I was able to demonstrate the application\nin action.<\/p>\n\n![\"Cluster](\"\/img\/kubecon-eu-2026-capi.jpg\")
<\/p>\n\n![\"Maintainer](\"\/img\/kubecon-eu-2026-unconference.jpg\")
<\/p>\n\n\n
![\"Maintainer](\"\/img\/kubecon-eu-2026-jack-kuba.jpg\")
<\/p>\n\n![\"Justin](\"\/img\/kubecon-eu-2026-justin-me.jpg\")
<\/p>\n\nWorkload Aware Scheduling Design Summit at Google, Monday March 23<\/h2>\n\n
![\"John](\"\/img\/kubecon-eu-2026-was-summit.jpg\")
<\/p>\n\nKubeCon Day 1, Tuesday March 24<\/h2>\n\n
![\"Community](\"\/img\/kubecon-eu-2026-communityhub.jpg\")
<\/p>\n\n![\"Curling](\"\/img\/kubecon-eu-2026-curling.jpg\")
<\/p>\n\nKubeCon Day 2, Wednesday March 25<\/h2>\n\n
![\"Cloud](\"\/img\/kubecon-eu-2026-cloudprovider-panel.jpg\")
<\/p>\n\nKubeCon Day 3, Thursday March 26<\/h2>\n\n
![\"Bootc](\"\/img\/kubecon-eu-2026-bootc.jpg\")
<\/p>\n\nA note on AI<\/h3>\n\n
![\"ai](\"\/img\/kubecon-eu-2026-ai.jpg\")
<\/p>\n\nThoughts and takeaways<\/h2>\n\n
\n
![\"rainy](\"\/img\/kubecon-eu-2026-outro.jpg\")
<\/p>\n\n","pubDate":"Wed, 08 Apr 2026 00:00:00 +0000","link":"https:\/\/notes.elmiko.dev\/2026\/04\/08\/kubecon-eu-2026-retrospective.html","guid":"https:\/\/notes.elmiko.dev\/2026\/04\/08\/kubecon-eu-2026-retrospective.html"},{"title":"KubeCon North America 2025 Retrospective","description":"![\"Selfie](\"\/img\/kubecon-na-2025-selfie.jpg\")
<\/p>\n\nKubernetes Maintainer Summit, Sunday November 9<\/h2>\n\n
OpenShift Commons and co-located events, Monday November 10<\/h2>\n\n
![\"Waffle](\"\/img\/kubecon-na-2025-wh.jpg\")
<\/p>\n\nKubeCon Day 1, Tuesday November 11<\/h2>\n\n
![\"Antonio,](\"\/img\/kubecon-na-2025-powertrio.jpg\")
\nAntonio, Ben, and Maciej, what a kubernetes power trio!<\/p>\n\nKubeCon Day 2, Wednesday November 12<\/h2>\n\n
![\"JK,](\"\/img\/kubecon-na-2025-ourtalk.jpg\")
\nJingkang, myself, and Praseeda, another power trio!<\/p>\n\n![\"SIG](\"\/img\/kubecon-na-2025-mng.jpg\")
\nIt was so good that the CNCF photographers caught us! (source<\/a>)<\/p>\n\n![\"Puppy](\"\/img\/kubecon-na-2025-puppy.jpg\")
<\/p>\n\n![\"Alternate](\"\/img\/kubecon-na-2025-karpcapi.jpg\")
<\/p>\n\nKubeCon Day 3, Thursday November 13<\/h2>\n\n
![\"SIG](\"\/img\/kubecon-na-2025-sigcp.jpg\")
<\/p>\n\nThoughts and takeaways<\/h2>\n\n
\n
![\"Atlanta\"](\"\/img\/kubecon-na-2025-atlanta.jpg\")
<\/p>\n\n","pubDate":"Mon, 17 Nov 2025 00:00:00 +0000","link":"https:\/\/notes.elmiko.dev\/2025\/11\/17\/kubecon-na-2025-retrospective.html","guid":"https:\/\/notes.elmiko.dev\/2025\/11\/17\/kubecon-na-2025-retrospective.html"},{"title":"KubeCon North America 2024 Retrospective","description":"![\"Selfie](\"\/img\/kubecon-na-2024-outfront.jpg\")
<\/p>\n\nCloud Native Rejekts, Sunday November 10<\/h2>\n\n
\n
Kubernetes Contributor Summit, Monday November 11<\/h2>\n\n
\n
OpenShift Commons, Tuesday November 12<\/h2>\n\n
![\"openshift](\"\/img\/kubecon-na-2024-keycaps.jpg\")
<\/p>\n\nKubeCon Day 1, Wednesday November 13<\/h2>\n\n
![\"inflatable](\"\/img\/kubecon-na-2024-curling.jpg\")
<\/p>\n\n\n
![\"red](\"\/img\/kubecon-na-2024-booth.jpg\")
<\/p>\n\nKubeCon Day 2, Thursday November 14<\/h2>\n\n
\n
\n
\n
\n
KubeCon Day 3, Friday November 15<\/h2>\n\n
\n
\n
![\"looking](\"\/img\/kubecon-na-2024-leaving.jpg\")
<\/p>\n\nThoughts and takeaways<\/h2>\n\n
\n
![\"Karpenter](\"\/img\/karpcapi-logo.svg\"){kind=logo}
<\/p>\n\nPlanning the foundation<\/h2>\n\n
Initial code and trajectory<\/h2>\n\n
\/\/ Create launches a NodeClaim with the given resource requests and requirements and returns a hydrated<\/span>\n\t\/\/ NodeClaim back with resolved NodeClaim labels for the launched NodeClaim<\/span>\n\tCreate<\/span>(<\/span>context<\/span>.<\/span>Context<\/span>,<\/span> *<\/span>v1<\/span>.<\/span>NodeClaim<\/span>)<\/span> (<\/span>*<\/span>v1<\/span>.<\/span>NodeClaim<\/span>,<\/span> error<\/span>)<\/span>\n\t\/\/ Delete removes a NodeClaim from the cloudprovider by its provider id<\/span>\n\tDelete<\/span>(<\/span>context<\/span>.<\/span>Context<\/span>,<\/span> *<\/span>v1<\/span>.<\/span>NodeClaim<\/span>)<\/span> error<\/span>\n\t\/\/ Get retrieves a NodeClaim from the cloudprovider by its provider id<\/span>\n\tGet<\/span>(<\/span>context<\/span>.<\/span>Context<\/span>,<\/span> string<\/span>)<\/span> (<\/span>*<\/span>v1<\/span>.<\/span>NodeClaim<\/span>,<\/span> error<\/span>)<\/span>\n\t\/\/ List retrieves all NodeClaims from the cloudprovider<\/span>\n\tList<\/span>(<\/span>context<\/span>.<\/span>Context<\/span>)<\/span> ([]<\/span>*<\/span>v1<\/span>.<\/span>NodeClaim<\/span>,<\/span> error<\/span>)<\/span>\n\t\/\/ GetInstanceTypes returns instance types supported by the cloudprovider.<\/span>\n\t\/\/ Availability of types or zone may vary by nodepool or over time. Regardless of<\/span>\n\t\/\/ availability, the GetInstanceTypes method should always return all instance types,<\/span>\n\t\/\/ even those with no offerings available.<\/span>\n\tGetInstanceTypes<\/span>(<\/span>context<\/span>.<\/span>Context<\/span>,<\/span> *<\/span>v1<\/span>.<\/span>NodePool<\/span>)<\/span> ([]<\/span>*<\/span>InstanceType<\/span>,<\/span> error<\/span>)<\/span>\n\t\/\/ DisruptionReasons is for CloudProviders to hook into the Disruption Controller.<\/span>\n\t\/\/ Reasons will show up as StatusConditions on the NodeClaim.<\/span>\n\tDisruptionReasons<\/span>()<\/span> []<\/span>v1<\/span>.<\/span>DisruptionReason<\/span>\n\t\/\/ IsDrifted returns whether a NodeClaim has drifted from the provisioning requirements<\/span>\n\t\/\/ it is tied to.<\/span>\n\tIsDrifted<\/span>(<\/span>context<\/span>.<\/span>Context<\/span>,<\/span> *<\/span>v1<\/span>.<\/span>NodeClaim<\/span>)<\/span> (<\/span>DriftReason<\/span>,<\/span> error<\/span>)<\/span>\n\t\/\/ Name returns the CloudProvider implementation name.<\/span>\n\tName<\/span>()<\/span> string<\/span>\n\t\/\/ GetSupportedNodeClasses returns CloudProvider NodeClass that implements status.Object<\/span>\n\t\/\/ NOTE: It returns a list where the first element should be the default NodeClass<\/span>\n\tGetSupportedNodeClasses<\/span>()<\/span> []<\/span>status<\/span>.<\/span>Object<\/span>\n}<\/span>\n<\/code><\/pre><\/div><\/div>\n\nCreate<\/code> method. In Cluster API\nthe creation of new Machines (the API type associated with a Node\u2019s instance) is controlled by a scale\nsubresource on another API type. This relationship is similar to that of a Pod to a ReplicationController or\nDeployment in that an increase in a replica count will trigger the creation of new resources. This means\nthat we must increase the replica count, and then wait for the Machine resource to be created before we\nknow the identifying information about the infrastructure resource. Karpenter, in contrast, would like to\nknow that identifying information when Create<\/code> returns, and this causes the synchronicity issue between the two.<\/p>\n\nA note on code structure<\/h3>\n\n
Handling custom resources<\/h2>\n\n
Testing<\/h2>\n\n
Proof of concept<\/h2>\n\n