Suggested Reads

The global conversation on what constitutes "Open Source AI" continues, hosted by the Open Source Initiative.

The carmakers are being sued for failing to install a basic anti-theft device in millions of cars.

The UK deal has drawn fire from civil liberties groups.

Authors : Bob Killen (Google), Chris Short (AWS), Jeremy Rickard (Microsoft), Marko Mudrinić (Kubermatic), Tim Bannister (The Scale Factory)On August 15, 2023, the Kubernetes project announced the general availability ofthe community-owned package repositories for Debian and RPM packages availableat pkgs.k8s.io . The new package repositories are replacement for the legacyGoogle-hosted package repositories: apt.kubernetes.io and yum.kubernetes.io .Theannouncement blog post for pkgs.k8s.iohighlighted that we will stop publishing packages to the legacy repositories inthe future.Today, we're formally deprecating the legacy package repositories (apt.kubernetes.ioand yum.kubernetes.io ), and we're announcing our plans to freeze the contents ofthe repositories as of September 13, 2023 .Please continue reading in order to learn what does this mean for you as an user ordistributor, and what steps you may need to take.How does this affect me as a Kubernetes end user?This change affects users directly installing upstream versions of Kubernetes ,either manually by following the officialinstallation andupgrade instructions, orby using a Kubernetes installer that's using packages provided by the Kubernetesproject.This change also affects you if you run Linux on your own PC and have installed kubectl using the legacy package repositories .We'll explain later on how to check if you're affected.If you use fully managed Kubernetes, for example through a service from a cloudprovider, you would only be affected by this change if you also installed kubectlon your Linux PC using packages from the legacy repositories. Cloud providers aregenerally using their own Kubernetes distributions and therefore they don't usepackages provided by the Kubernetes project; more importantly, if someone else ismanaging Kubernetes for you, then they would usually take responsibility for that check.If you have a managed control planebut you are responsible for managing the nodes yourself , and any of those nodes run Linux,you should check whether you are affected.If you're managing your clusters on your own by following the official installationand upgrade instructions, please follow the instructions in this blog post to migrateto the (new) community-owned package repositories.If you're using a Kubernetes installer that's using packages provided by theKubernetes project, please check the installer tool's communication channels forinformation about what steps you need to take, and eventually if needed, follow upwith maintainers to let them know about this change.How does this affect me as a Kubernetes distributor?If you're using the legacy repositories as part of your project (e.g. a Kubernetesinstaller tool), you should migrate to the community-owned repositories as soon aspossible and inform your users about this change and what steps they need to take.Timeline of changes15th August 2023:Kubernetes announces a new, community-managed source for Linux software packages of Kubernetes components31st August 2023:(this announcement) Kubernetes formally deprecates the legacypackage repositories13th September 2023 (approximately):Kubernetes will freeze the legacy package repositories,(apt.kubernetes.io and yum.kubernetes.io ).The freeze will happen immediately following the patch releases that are scheduled for September, 2023.The Kubernetes patch releases scheduled for September 2023 (v1.28.2, v1.27.6,v1.26.9, v1.25.14) will have packages published both to the community-owned andthe legacy repositories.We'll freeze the legacy repositories after cutting the patch releases for Septemberwhich means that we'll completely stop publishing packages to the legacy repositoriesat that point.For the v1.28, v1.27, v1.26, and v1.25 patch releases from October 2023 and onwards,we'll only publish packages to the new package repositories (pkgs.k8s.io ).What about future minor releases?Kubernetes 1.29 and onwards will have packages published only to thecommunity-owned repositories (pkgs.k8s.io ).Can I continue to use the legacy package repositories?The existing packages in the legacy repositories will be available for the foreseeablefuture. However, the Kubernetes project can't provide any guarantees on how longis that going to be. The deprecated legacy repositories, and their contents, mightbe removed at any time in the future and without a further notice period.The Kubernetes project strongly recommends migrating to the new community-ownedrepositories as soon as possible .Given that no new releases will be published to the legacy repositories after the September 13, 2023cut-off point, you will not be able to upgrade to any patch or minor release made from that date onwards.Whilst the project makes every effort to release secure software, there may oneday be a high-severity vulnerability in Kubernetes, and consequently an importantrelease to upgrade to. The advice we're announcing will help you be as prepared forany future security update, whether trivial or urgent.How can I check if I'm using the legacy repositories?The steps to check if you're using the legacy repositories depend on whether you'reusing Debian-based distributions (Debian, Ubuntu, and more) or RPM-based distributions(CentOS, RHEL, Rocky Linux, and more) in your cluster.Run these instructions on one of your nodes in the cluster.Debian-based Linux distributionsThe repository definitions (sources) are located in /etc/apt/sources.list and /etc/apt/sources.list.d/on Debian-based distributions. Inspect these two locations and try to locate apackage repository definition that looks like:deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial mainIf you find a repository definition that looks like this, you're using the legacy repository and you need to migrate.If the repository definition uses pkgs.k8s.io , you're already using thecommunity-hosted repositories and you don't need to take any action.On most systems, this repository definition should be located in/etc/apt/sources.list.d/kubernetes.list (as recommended by the Kubernetesdocumentation), but on some systems it might be in a different location.If you can't find a repository definition related to Kubernetes, it's likely that youdon't use package managers to install Kubernetes and you don't need to take any action.RPM-based Linux distributionsThe repository definitions are located in /etc/yum.repos.d if you're using theyum package manager, or /etc/dnf/dnf.conf and /etc/dnf/repos.d/ if you're usingdnf package manager. Inspect those locations and try to locate a package repositorydefinition that looks like this:[kubernetes]name=Kubernetesbaseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearchenabled=1gpgcheck=1gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpgexclude=kubelet kubeadm kubectlIf you find a repository definition that looks like this, you're using the legacy repository and you need to migrate.If the repository definition uses pkgs.k8s.io , you're already using thecommunity-hosted repositories and you don't need to take any action.On most systems, that repository definition should be located in /etc/yum.repos.d/kubernetes.repo(as recommended by the Kubernetes documentation), but on some systems it might bein a different location.If you can't find a repository definition related to Kubernetes, it's likely that youdon't use package managers to install Kubernetes and you don't need to take any action.How can I migrate to the new community-operated repositories?For more information on how to migrate to the new communitymanaged packages, please refer to theannouncement blog post for pkgs.k8s.io .Why is the Kubernetes project making this change?Kubernetes has been publishing packages solely to the Google-hosted repositorysince Kubernetes v1.5, or the past seven years! Following in the footsteps ofmigrating to our community-managed registry, registry.k8s.io , we are now migrating theKubernetes package repositories to our own community-managed infrastructure. We’rethankful to Google for their continuous hosting and support all these years, butthis transition marks another big milestone for the project’s goal of migratingto complete community-owned infrastructure.Is there a Kubernetes tool to help me migrate?We don't have any announcement to make about tooling there. As a Kubernetes user, youhave to manually modify your configuration to use the new repositories. Automatingthe migration from the legacy to the community-owned repositories is technicallychallenging and we want to avoid any potential risks associated with this.AcknowledgmentsFirst of all, we want to acknowledge the contributions from Alphabet. Staff at Googlehave provided their time; Google as a business has provided both the infrastructureto serve packages, and the security context for giving those packages trustworthydigital signatures.These have been important to the adoption and growth of Kubernetes.Releasing software might not be glamorous but it's important. Many people withinthe Kubernetes contributor community have contributed to the new way that we, as aproject, have for building and publishing packages.And finally, we want to once again acknowledge the help from SUSE. OpenBuildService,from SUSE, is the technology that the powers the new community-managed package repositories.

As part of updates to the older file-system drivers for Linux 6.6, the ReiserFS file-system is no longer marked as 'Supported' but is officially treated as 'Obsolete' within the Linux kernel.

X is expanding the amount of data it collects.

Comcast and other ISPs asked FCC to ditch listing-every-fee rule. FCC says "no."

Apple is planning to eliminate social media support advisor roles across Twitter, YouTube, and the Apple Support Community website starting later...

Google this morning announced that it will be hosting its annual Pixel hardware event on Wednesday, October 4...

Google uses search takedowns to "moderate" users' privately saved links collections, used by some as bookmarks.

A Saudi court has sentenced a man to death over his posts on X, formerly known as Twitter, and his activity on YouTube.

Moving forward Google engineers are working to roll-out new Chrome stable releases even faster.

A state-backed enterprise in China’s southern Guangdong province has apologised after admitting that its ‘home-developed’ software was based on open-source code licensed from US tech giant Microsoft.

This blog is based on a session we presented at DEF CON 2023 on Friday, August 11, 2023, in Las Vegas: Contain Yourself: Staying Undetected Using the Windows Container Isolation Framework.

Today we are announcing the retirement of the Visual Studio for Mac IDE. Visual Studio for Mac 17.6 will continue to be supported for another 12 months, until August 31st, 2024, with servicing updates for security issues and updated platforms from Apple.

Using a monorepo causes a lot of performance challenges for git. Here's how we solve them at Canva.

Does running MySQL on Kubernetes lead to significant performance degradation?

Use ftrace to debug inability to mount sysfs in unshared user namespace.

Linux Virtual Networking. GitHub Gist: instantly share code, notes, and snippets.

Security Enhanced Linux (SELinux) has been part of the mainline kernel for two decades to provide a security module implementing access control security policies and is now widely-used for enhancing the security of production Linux servers and other systems

Netflix’s service mesh adoption: history, motivations, and how we worked with the Envoy community on a feature to streamline mesh adoption

Introduction Today, we’re excited to announce the native support for enforcing Kubernetes network policies with Amazon VPC Container Networking Interface (CNI) Plugin. You can now use Amazon VPC CNI to implement both pod networking and network policies to secure the traffic in your Kubernetes clusters. Native support for network policies has been one of the […]

Apple will receive all of TSMC's first-generation 3-nanometer process chips this year for upcoming iPhones, Macs, and iPads, according to...

Public Knowledge and iFixit want the right to repair commercial kitchen gear.

On 23 February, 2017 the SHAttered attack demonstrated a practical SHA-1 hash collision. While it does not directly affect Git, it's only a matter of time before attacks are found against it. The NIST has started recommending to STOP using SHA-1 back in 2006! With v2.42.0 Git has finally marked

Phylum routinely identifies malware and other software supply chain attacks targeting high-value, critical assets: an organization’s software developers. Most recently, we’ve reported on a flurry of sophisticated attacks targeting JavaScript developers, respawning malware on PyPI, and were the first to identify North Korean state actors publishing malicious packages

Authors: Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google) We are thrilled to announce the v0.8.0 release of Gateway API! With this release, Gateway API support for service mesh has reached Experimental status . We look forward to your feedback! We're especially delighted to announce that Kuma 2.3+, Linkerd 2.14+, and Istio 1.16+ are all fully-conformant implementations of Gateway API service mesh support. Service mesh support in Gateway API While the initial focus of Gateway API was always ingress (north-south) traffic, it was clear almost from the beginning that the same basic routing concepts should also be applicable to service mesh (east-west) traffic. In 2022, the Gateway API subproject started the GAMMA initiative , a dedicated vendor-neutral workstream, specifically to examine how best to fit service mesh support into the framework of the Gateway API resources, without requiring users of Gateway API to relearn everything they understand about the API. Over the last year, GAMMA has dug deeply into the challenges and possible solutions around using Gateway API for service mesh. The end result is a small number of enhancement proposals that subsume many hours of thought and debate, and provide a minimum viable path to allow Gateway API to be used for service mesh. How will mesh routing work when using Gateway API? You can find all the details in the Gateway API Mesh routing documentation and GEP-1426 , but the short version for Gateway API v0.8.0 is that an HTTPRoute can now have a parentRef that is a Service, rather than just a Gateway. We anticipate future GEPs in this area as we gain more experience with service mesh use cases -- binding to a Service makes it possible to use the Gateway API with a service mesh, but there are several interesting use cases that remain difficult to cover. As an example, you might use an HTTPRoute to do an A-B test in the mesh as follows: apiVersion : gateway.networking.k8s.io/v1beta1 kind : HTTPRoute metadata : name : bar-route spec : parentRefs : - group : "" kind : Service name : demo-app port : 5000 rules : - matches : - headers : - type : Exact name : env value : v1 backendRefs : - name : demo-app-v1 port : 5000 - backendRefs : - name : demo-app-v2 port : 5000 Any request to port 5000 of the demo-app Service that has the header env: v1 will be routed to demo-app-v1 , while any request without that header will be routed to demo-app-v2 -- and since this is being handled by the service mesh, not the ingress controller, the A/B test can happen anywhere in the application's call graph. How do I know this will be truly portable? Gateway API has been investing heavily in conformance tests across all features it supports, and mesh is no exception. One of the challenges that the GAMMA initiative ran into is that many of these tests were strongly tied to the idea that a given implementation provides an ingress controller. Many service meshes don't, and requiring a GAMMA-conformant mesh to also implement an ingress controller seemed impractical at best. This resulted in work restarting on Gateway API conformance profiles , as discussed in GEP-1709 . The basic idea of conformance profiles is that we can define subsets of the Gateway API, and allow implementations to choose (and document) which subsets they conform to. GAMMA is adding a new profile, named Mesh and described in GEP-1686 , which checks only the mesh functionality as defined by GAMMA. At this point, Kuma 2.3+, Linkerd 2.14+, and Istio 1.16+ are all conformant with the Mesh profile. What else is in Gateway API v0.8.0? This release is all about preparing Gateway API for the upcoming v1.0 release where HTTPRoute, Gateway, and GatewayClass will graduate to GA. There are two main changes related to this: CEL validation and API version changes. CEL Validation The first major change is that Gateway API v0.8.0 is the start of a transition from webhook validation to CEL validation using information built into the CRDs. That will mean different things depending on the version of Kubernetes you're using: Kubernetes 1.25+ CEL validation is fully supported, and almost all validation is implemented in CEL. (The sole exception is that header names in header modifier filters can only do case-insensitive validation. There is more information in issue 2277 .) We recommend not using the validating webhook on these Kubernetes versions. Kubernetes 1.23 and 1.24 CEL validation is not supported, but Gateway API v0.8.0 CRDs can still be installed. When you upgrade to Kubernetes 1.25+, the validation included in these CRDs will automatically take effect. We recommend continuing to use the validating webhook on these Kubernetes versions. Kubernetes 1.22 and older Gateway API only commits to support for 5 most recent versions of Kubernetes . As such, these versions are no longer supported by Gateway API, and unfortunately Gateway API v0.8.0 cannot be installed on them, since CRDs containing CEL validation will be rejected. API Version Changes As we prepare for a v1.0 release that will graduate Gateway, GatewayClass, and HTTPRoute to the v1 API Version from v1beta1 , we are continuing the process of moving away from v1alpha2 for resources that have graduated to v1beta1 . For more information on this change and everything else included in this release, refer to the v0.8.0 release notes . How can I get started with Gateway API? Gateway API represents the future of load balancing, routing, and service mesh APIs in Kubernetes. There are already more than 20 implementations available (including both ingress controllers and service meshes) and the list keeps growing. If you're interested in getting started with Gateway API, take a look at the API concepts documentation and check out some of the Guides to try it out. Because this is a CRD-based API, you can install the latest version on any Kubernetes 1.23+ cluster. If you're specifically interested in helping to contribute to Gateway API, we would love to have you! Please feel free to open a new issue on the repository, or join in the discussions . Also check out the community page which includes links to the Slack channel and community meetings. We look forward to seeing you!! Further Reading: GEP-1324 provides an overview of the GAMMA goals and some important definitions. This GEP is well worth a read for its discussion of the problem space. GEP-1426 defines how to use Gateway API route resources, such as HTTPRoute, to manage traffic within a service mesh. GEP-1686 builds on the work of GEP-1709 to define a conformance profile for service meshes to be declared conformant with Gateway API. Although these are Experimental patterns, note that they are available in the standard release channel , since the GAMMA initiative has not needed to introduce new resources or fields to date.