27 Jul 2024
Hacker News
Guish: Write shell pipelines at the command line with a GUI editor
27 Jul 2024 2:48am GMT
Windows Recovery Environment and Bootable USB Creator in 200KB
27 Jul 2024 2:09am GMT
The Linux Kernel Module Programming Guide
27 Jul 2024 2:04am GMT
26 Jul 2024
Linuxiac
Funtoo Linux Project Being Discontinued?
Funtoo Linux to end? Founder Daniel Robbins announces the project's closure in August. Full story here.
26 Jul 2024 11:46pm GMT
Immich Hits Milestone with 40,000 Stars on GitHub
Immich, a self-hosted photos and videos backup solution, celebrates 40K stars with v1.110, which brings self-hosted maps and revised purchase terms.
26 Jul 2024 7:01pm GMT
Fwupd 1.9.22 Brings Unofficial Raspberry Pi 5 Support
The latest fwupd 1.9.22 firmware update daemon addresses multiple bugs and adds support for Framework SD and Raspberry Pi 5.
26 Jul 2024 4:47pm GMT
OMG! Ubuntu
VirtualBox 7.1 Beta: ‘Modernised’ UI, Wayland Clipboard Sharing + More
If you plan on trying the new Linux Mint 22 release in a virtual machine, why not double-up the fun by taking it for a spin in the VirtualBox 7.1 beta, which slipped out last night. Don't tune out-most VirtualBox updates are fairly modest, I know. But the upcoming release of VirtualBox 7.1? It's being billed by Oracle as a 'major update' - about time too, I say! VirtualBox 7.1 introduces a "modernized look and feel" that gives users with a choice of UI mode: Basic streamlines the interface, reducing the amount of options, settings, and details shown; Expert puts […]
You're reading VirtualBox 7.1 Beta: 'Modernised' UI, Wayland Clipboard Sharing + More, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
26 Jul 2024 1:25pm GMT
Ubuntu blog
MongoDB® use cases for the telecommunications industry
MongoDB® is one of the most widely used databases (DB Engines, 2024) for enterprises, including those in the telecommunications industry. It provides a sturdy, adaptable and trustworthy foundation. It also safeguards sensitive customer data while facilitating swift responses to rapidly evolving situations.
With that in mind, let's take a look at the key use cases for MongoDB in the telco sector and the advantages that this solution brings to the table.
26 Jul 2024 12:07pm GMT
Canonical to present keynote session at Kubecon China 2024
We are excited to announce that, on the 21st of August 2024, product managers Andreea Munteanu (AI) and Adrian Matei (Managed Services) will represent Canonical in a keynote session at Kubecon China, at the Kerry Hotel in Hong Kong. Canonical has been a regular presence at Kubecon events over the years, and we are excited to […]
26 Jul 2024 10:30am GMT
25 Jul 2024
Ubuntu blog
Meet us in Sydney and let’s talk about how you can navigate your AI journey
Date: August 27, 2024 Venue: The Fullerton Hotel Sydney Time: 13:00 PM - 18:00 PM AI has officially taken off. Today, thousands of exciting projects are being taken to production in all industries, while a report by Deloitte found that use of gen AI by employees at Australian workplaces rose to 38% in 2023. Despite […]
25 Jul 2024 3:29pm GMT
OMG! Ubuntu
Linux Mint 22 Officially Released, This is What’s New
And we're go - Linux Mint 22 'Wilma' has been officially released and made available to download. This major update is the first to be based on Ubuntu 24.04 LTS This major update is built on Ubuntu 24.04 LTS and sees Linux Mint 22 inherit big updates to underlying packages, libraries, tooling, and core technology stacks. There's also a new Linux kernel, and a fresh set of graphics drivers. Linux Mint 22 ships with a new version of the Cinnamon desktop (featuring new options), a suite of new and improved apps (plus a few downgrades and removals), and makes some […]
You're reading Linux Mint 22 Officially Released, This is What's New, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
25 Jul 2024 1:35pm GMT
JavaScript Weekly
What's new for us in ECMAScript 2024
|
25 Jul 2024 12:00am GMT
24 Jul 2024
OMG! Ubuntu
A $60 Intel-Based SBC Cheaper & Faster than a Raspberry Pi 5
Love the idea of tinkering around with a small, single-board computer (SBC) but need something more powerful than most ARM-based offerings provide? If so, the new Radxa X4 from Radxa may be of interest. Powered by an Intel N100 CPU with Intel UHD graphics, the Radxa X4 delivers better performance in CPU and GPU tasks than a Raspberry Pi 5, at a similar price point. It won't match ARM-based devices in power consumption, and will run a bit hotter under load too. Like the Pi -I'd stop comparing but hey: I picked my narrative hook and I aim to run […]
You're reading A $60 Intel-Based SBC Cheaper & Faster than a Raspberry Pi 5, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
24 Jul 2024 2:37pm GMT
19 Jul 2024
Kubernetes Blog
Kubernetes Removals and Major Changes In v1.31
As Kubernetes develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. This article outlines some planned changes for the Kubernetes v1.31 release that the release team feels you should be aware of for the continued maintenance of your Kubernetes environment. The information listed below is based on the current status of the v1.31 release. It may change before the actual release date.
The Kubernetes API removal and deprecation process
The Kubernetes project has a well-documented deprecation policy for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release. It will continue to function until removal (at least one year from the deprecation), but usage will display a warning. Removed APIs are no longer available in the current version, so you must migrate to using the replacement.
-
Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes.
-
Beta or pre-release API versions must be supported for 3 releases after the deprecation.
-
Alpha or experimental API versions may be removed in any release without prior deprecation notice.
Whether an API is removed because a feature graduated from beta to stable or because that API did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the documentation.
A note about SHA-1 signature support
In go1.18 (released in March 2022), the crypto/x509 library started to reject certificates signed with a SHA-1 hash function. While SHA-1 is established to be unsafe and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015, there might still be cases in the context of Kubernetes where user-provided certificates are signed using a SHA-1 hash function through private authorities with them being used for Aggregated API Servers or webhooks. If you have relied on SHA-1 based certificates, you must explicitly opt back into its support by setting GODEBUG=x509sha1=1 in your environment.
Given Go's compatibility policy for GODEBUGs, the x509sha1 GODEBUG and the support for SHA-1 certificates will fully go away in go1.24 which will be released in the first half of 2025. If you rely on SHA-1 certificates, please start moving off them.
Please see Kubernetes issue #125689 to get a better idea of timelines around the support for SHA-1 going away, when Kubernetes releases plans to adopt go1.24, and for more details on how to detect usage of SHA-1 certificates via metrics and audit logging.
Deprecations and removals in Kubernetes 1.31
Deprecation of status.nodeInfo.kubeProxyVersion field for Nodes (KEP 4004)
The .status.nodeInfo.kubeProxyVersion field of Nodes is being deprecated in Kubernetes v1.31, and will be removed in a later release. It's being deprecated because the value of this field wasn't (and isn't) accurate. This field is set by the kubelet, which does not have reliable information about the kube-proxy version or whether kube-proxy is running.
The DisableNodeKubeProxyVersion feature gate will be set to true in by default in v1.31 and the kubelet will no longer attempt to set the .status.kubeProxyVersion field for its associated Node.
Removal of all in-tree integrations with cloud providers
As highlighted in a previous article, the last remaining in-tree support for cloud provider integration will be removed as part of the v1.31 release. This doesn't mean you can't integrate with a cloud provider, however you now must use the recommended approach using an external integration. Some integrations are part of the Kubernetes project and others are third party software.
This milestone marks the completion of the externalization process for all cloud providers' integrations from the Kubernetes core (KEP-2395), a process started with Kubernetes v1.26. This change helps Kubernetes to get closer to being a truly vendor-neutral platform.
For further details on the cloud provider integrations, read our v1.29 Cloud Provider Integrations feature blog. For additional context about the in-tree code removal, we invite you to check the (v1.29 deprecation blog).
The latter blog also contains useful information for users who need to migrate to version v1.29 and later.
Removal of kubelet --keep-terminated-pod-volumes command line flag
The kubelet flag --keep-terminated-pod-volumes, which was deprecated in 2017, will be removed as part of the v1.31 release.
You can find more details in the pull request #122082.
Removal of CephFS volume plugin
CephFS volume plugin was removed in this release and the cephfs volume type became non-functional.
It is recommended that you use the CephFS CSI driver as a third-party storage driver instead. If you were using the CephFS volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.
CephFS volume plugin was formally marked as deprecated in v1.28.
Removal of Ceph RBD volume plugin
The v1.31 release will remove the Ceph RBD volume plugin and its CSI migration support, making the rbd volume type non-functional.
It's recommended that you use the RBD CSI driver in your clusters instead. If you were using Ceph RBD volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.
The Ceph RBD volume plugin was formally marked as deprecated in v1.28.
Deprecation of non-CSI volume limit plugins in kube-scheduler
The v1.31 release will deprecate all non-CSI volume limit scheduler plugins, and will remove some already deprected plugins from the default plugins, including:
AzureDiskLimitsCinderLimitsEBSLimitsGCEPDLimits
It's recommended that you use the NodeVolumeLimits plugin instead because it can handle the same functionality as the removed plugins since those volume types have been migrated to CSI. Please replace the deprecated plugins with the NodeVolumeLimits plugin if you explicitly use them in the scheduler config. The AzureDiskLimits, CinderLimits, EBSLimits, and GCEPDLimits plugins will be removed in a future release.
These plugins will be removed from the default scheduler plugins list as they have been deprecated since Kubernetes v1.14.
Looking ahead
The official list of API removals planned for Kubernetes v1.32 include:
- The
flowcontrol.apiserver.k8s.io/v1beta3API version of FlowSchema and PriorityLevelConfiguration will be removed. To prepare for this, you can edit your existing manifests and rewrite client software to use theflowcontrol.apiserver.k8s.io/v1 APIversion, available since v1.29. All existing persisted objects are accessible via the new API. Notable changes in flowcontrol.apiserver.k8s.io/v1beta3 include that the PriorityLevelConfigurationspec.limited.nominalConcurrencySharesfield only defaults to 30 when unspecified, and an explicit value of 0 is not changed to 30.
For more information, please refer to the API deprecation guide.
Want to know more?
The Kubernetes release notes announce deprecations. We will formally announce the deprecations in Kubernetes v1.31 as part of the CHANGELOG for that release.
You can see the announcements of pending deprecations in the release notes for:
19 Jul 2024 12:00am GMT
18 Jul 2024
JavaScript Weekly
Exploring JavaScript (ES2024 Edition)
|
18 Jul 2024 12:00am GMT
11 Jul 2024
JavaScript Weekly
Do the (ESLint) Evolution
|
11 Jul 2024 12:00am GMT
20 Jun 2024
Kubernetes Blog
Spotlight on SIG Node
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, Gunju Kim, and Sergey Kanzhelev, members of SIG Node, 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. I work as a Senior Kubernetes Developer for a security startup named ARMO, which donated Kubescape to the CNCF.
Gunju: My name is Gunju Kim. I am a software engineer at NAVER, 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 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 - 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 (e.g. containerd and CRI-O, 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) 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 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.
20 Jun 2024 12:00am GMT
06 Jun 2024
Kubernetes Blog
10 Years of Kubernetes
Ten (10) years ago, on June 6th, 2014, the first commit of Kubernetes was pushed to GitHub. That first commit with 250 files and 47,501 lines of go, bash and markdown kicked off the project we have today. Who could have predicted that 10 years later, Kubernetes would grow to become one of the largest Open Source projects to date with over 88,000 contributors from more than 8,000 companies, across 44 countries.
This milestone isn't just for Kubernetes but for the Cloud Native ecosystem that blossomed from it. There are close to 200 projects within the CNCF itself, with contributions from 240,000+ individual contributors and thousands more in the greater ecosystem. Kubernetes would not be where it is today without them, the 7M+ Developers, and the even larger user community that have all helped shape the ecosystem that it is today.
Kubernetes' beginnings - a converging of technologies
The ideas underlying Kubernetes started well before the first commit, or even the first prototype (which came about in 2013). In the early 2000s, Moore's Law was well in effect. Computing hardware was becoming more and more powerful at an incredibly fast rate. Correspondingly, applications were growing more and more complex. This combination of hardware commoditization and application complexity pointed to a need to further abstract software from hardware, and solutions started to emerge.
Like many companies at the time, Google was scaling rapidly, and its engineers were interested in the idea of creating a form of isolation in the Linux kernel. Google engineer Rohit Seth described the concept in an email in 2006:
We use the term container to indicate a structure against which we track and charge utilization of system resources like memory, tasks, etc. for a Workload.
In March of 2013, a 5-minute lightning talk called "The future of Linux Containers," presented by Solomon Hykes at PyCon, introduced an upcoming open source tool called "Docker" for creating and using Linux Containers. Docker introduced a level of usability to Linux Containers that made them accessible to more users than ever before, and the popularity of Docker, and thus of Linux Containers, skyrocketed. With Docker making the abstraction of Linux Containers accessible to all, running applications in much more portable and repeatable ways was suddenly possible, but the question of scale remained.
Google's Borg system for managing application orchestration at scale had adopted Linux containers as they were developed in the mid-2000s. Since then, the company had also started working on a new version of the system called "Omega." Engineers at Google who were familiar with the Borg and Omega systems saw the popularity of containerization driven by Docker. They recognized not only the need for an open source container orchestration system but its "inevitability," as described by Brendan Burns in this blog post. That realization in the fall of 2013 inspired a small team to start working on a project that would later become Kubernetes. That team included Joe Beda, Brendan Burns, Craig McLuckie, Ville Aikas, Tim Hockin, Dawn Chen, Brian Grant, and Daniel Smith.
A decade of Kubernetes
Kubernetes' history begins with that historic commit on June 6th, 2014, and the subsequent announcement of the project in a June 10th keynote by Google engineer Eric Brewer at DockerCon 2014 (and its corresponding Google blog).
Over the next year, a small community of contributors, largely from Google and Red Hat, worked hard on the project, culminating in a version 1.0 release on July 21st, 2015. Alongside 1.0, Google announced that Kubernetes would be donated to a newly formed branch of the Linux Foundation called the Cloud Native Computing Foundation (CNCF).
Despite reaching 1.0, the Kubernetes project was still very challenging to use and understand. Kubernetes contributor Kelsey Hightower took special note of the project's shortcomings in ease of use and on July 7, 2016, he pushed the first commit of his famed "Kubernetes the Hard Way" guide.
The project has changed enormously since its original 1.0 release; experiencing a number of big wins such as Custom Resource Definitions (CRD) going GA in 1.16 or full dual stack support launching in 1.23 and community "lessons learned" from the removal of widely used beta APIs in 1.22 or the deprecation of Dockershim.
Some notable updates, milestones and events since 1.0 include:
- December 2016 - Kubernetes 1.5 introduces runtime pluggability with initial CRI support and alpha Windows node support. OpenAPI also appears for the first time, paving the way for clients to be able to discover extension APIs.
- This release also introduced StatefulSets and PodDisruptionBudgets in Beta.
- April 2017 - Introduction of Role-Based Access Controls or RBAC.
- June 2017 - In Kubernetes 1.7, ThirdPartyResources or "TPRs" are replaced with CustomResourceDefinitions (CRDs).
- December 2017 - Kubernetes 1.9 sees the Workloads API becoming GA (Generally Available). The release blog states: "Deployment and ReplicaSet, two of the most commonly used objects in Kubernetes, are now stabilized after more than a year of real-world use and feedback."
- December 2018 - In 1.13, the Container Storage Interface (CSI) reaches GA, kubeadm tool for bootstrapping minimum viable clusters reaches GA, and CoreDNS becomes the default DNS server.
- September 2019 - Custom Resource Definitions go GA in Kubernetes 1.16.
- August 2020 - Kubernetes 1.19 increases the support window for releases to 1 year.
- December 2020 - Dockershim is deprecated in 1.20
- April 2021 - the Kubernetes release cadence changes from 4 releases per year to 3 releases per year.
- July 2021 - Widely used beta APIs are removed in Kubernetes 1.22.
- May 2022 - Kubernetes 1.24 sees beta APIs become disabled by default to reduce upgrade conflicts and removal of Dockershim, leading to widespread user confusion (we've since improved our communication!)
- December 2022 - In 1.26, there was a significant batch and Job API overhaul that paved the way for better support for AI /ML / batch workloads.
PS: Curious to see how far the project has come for yourself? Check out this tutorial for spinning up a Kubernetes 1.0 cluster created by community members Carlos Santana, Amim Moises Salum Knabben, and James Spurin.
Kubernetes offers more extension points than we can count. Originally designed to work with Docker and only Docker, now you can plug in any container runtime that adheres to the CRI standard. There are other similar interfaces: CSI for storage and CNI for networking. And that's far from all you can do. In the last decade, whole new patterns have emerged, such as using
Custom Resource Definitions (CRDs) to support third-party controllers - now a huge part of the Kubernetes ecosystem.
The community building the project has also expanded immensely over the last decade. Using DevStats, we can see the incredible volume of contribution over the last decade that has made Kubernetes the second-largest open source project in the world:
- 88,474 contributors
- 15,121 code committers
- 4,228,347 contributions
- 158,530 issues
- 311,787 pull requests
Kubernetes today
Since its early days, the project has seen enormous growth in technical capability, usage, and contribution. The project is still actively working to improve and better serve its users.
In the upcoming 1.31 release, the project will celebrate the culmination of an important long-term project: the removal of in-tree cloud provider code. In this largest migration in Kubernetes history, roughly 1.5 million lines of code have been removed, reducing the binary sizes of core components by approximately 40%. In the project's early days, it was clear that extensibility would be key to success. However, it wasn't always clear how that extensibility should be achieved. This migration removes a variety of vendor-specific capabilities from the core Kubernetes code base. Vendor-specific capabilities can now be better served by other pluggable extensibility features or patterns, such as Custom Resource Definitions (CRDs) or API standards like the Gateway API. Kubernetes also faces new challenges in serving its vast user base, and the community is adapting accordingly. One example of this is the migration of image hosting to the new, community-owned registry.k8s.io. The egress bandwidth and costs of providing pre-compiled binary images for user consumption have become immense. This new registry change enables the community to continue providing these convenient images in more cost- and performance-efficient ways. Make sure you check out the blog post and update any automation you have to use registry.k8s.io!
The future of Kubernetes
A decade in, the future of Kubernetes still looks bright. The community is prioritizing changes that both improve the user experiences, and enhance the sustainability of the project. The world of application development continues to evolve, and Kubernetes is poised to change along with it.
In 2024, the advent of AI changed a once-niche workload type into one of prominent importance. Distributed computing and workload scheduling has always gone hand-in-hand with the resource-intensive needs of Artificial Intelligence, Machine Learning, and High Performance Computing workloads. Contributors are paying close attention to the needs of newly developed workloads and how Kubernetes can best serve them. The new Serving Working Group is one example of how the community is organizing to address these workloads' needs. It's likely that the next few years will see improvements to Kubernetes' ability to manage various types of hardware, and its ability to manage the scheduling of large batch-style workloads which are run across hardware in chunks.
The ecosystem around Kubernetes will continue to grow and evolve. In the future, initiatives to maintain the sustainability of the project, like the migration of in-tree vendor code and the registry change, will be ever more important.
The next 10 years of Kubernetes will be guided by its users and the ecosystem, but most of all, by the people who contribute to it. The community remains open to new contributors. You can find more information about contributing in our New Contributor Course at https://k8s.dev/docs/onboarding.
We look forward to building the future of Kubernetes with you!
06 Jun 2024 12:00am GMT