1_DevOps'ish

Yout.com calls for a pause on the RIAA's request for attorney's fees until the legality of youtube-dl-based software has been heard at appeal.

Google's initial plan to start Manifest V3 experiments in several versions the Chrome web browser have been postponed again by the company.

This session dives deeps into recent enhancements to Amazon EKS, a fully managed Kubernetes service. Learn how these new capabilities make it easy for you to run Kubernetes on AWS and on premises and help ensure the availability and scalability of your mission-critical applications. Learn more about AWS re:Invent at https://go.aws/3ikK4dD. Subscribe: More AWS videos http://bit.ly/2O3zS75 More AWS events videos http://bit.ly/316g9t4 ABOUT AWS Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts. AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster. #reInvent2022 #AWSreInvent2022 #AWSEvents

On Thursday, the U.S. Patent and Trademark Office published a patent application from Apple that relates to a wearable self-mixing interferometry (SMI) ring that could be used to sense physiological conditions of a user, such as a heart rate, blood oxygen saturation, blood pressure and more.

Authors : Brandon Smith (Microsoft) and Mark Rossetti (Microsoft) The long-awaited day has arrived: HostProcess containers, the Windows equivalent to Linux privileged containers, has finally made it to GA in Kubernetes 1.26 ! What are HostProcess containers and why are they useful? Cluster operators are often faced with the need to configure their nodes upon provisioning such as installing Windows services, configuring registry keys, managing TLS certificates, making network configuration changes, or even deploying monitoring tools such as a Prometheus's node-exporter. Previously, performing these actions on Windows nodes was usually done by running PowerShell scripts over SSH or WinRM sessions and/or working with your cloud provider's virtual machine management tooling. HostProcess containers now enable you to do all of this and more with minimal effort using Kubernetes native APIs. With HostProcess containers you can now package any payload into the container image, map volumes into containers at runtime, and manage them like any other Kubernetes workload. You get all the benefits of containerized packaging and deployment methods combined with a reduction in both administrative and development cost. Gone are the days where cluster operators would need to manually log onto Windows nodes to perform administrative duties. HostProcess containers differ quite significantly from regular Windows Server containers. They are run directly as processes on the host with the access policies of a user you specify. HostProcess containers run as either the built-in Windows system accounts or ephemeral users within a user group defined by you. HostProcess containers also share the host's network namespace and access/configure storage mounts visible to the host. On the other hand, Windows Server containers are highly isolated and exist in a separate execution namespace. Direct access to the host from a Windows Server container is explicitly disallowed by default. How does it work? Windows HostProcess containers are implemented with Windows Job Objects , a break from the previous container model which use server silos. Job Objects are components of the Windows OS which offer the ability to manage a group of processes as a group (also known as a job ) and assign resource constraints to the group as a whole. Job objects are specific to the Windows OS and are not associated with the Kubernetes Job API . They have no process or file system isolation, enabling the privileged payload to view and edit the host file system with the desired permissions, among other host resources. The init process, and any processes it launches (including processes explicitly launched by the user) are all assigned to the job object of that container. When the init process exits or is signaled to exit, all the processes in the job will be signaled to exit, the job handle will be closed and the storage will be unmounted. HostProcess and Linux privileged containers enable similar scenarios but differ greatly in their implementation (hence the naming difference). HostProcess containers have their own PodSecurityContext fields. Those used to configure Linux privileged containers do not apply. Enabling privileged access to a Windows host is a fundamentally different process than with Linux so the configuration and capabilities of each differ significantly. Below is a diagram detailing the overall architecture of Windows HostProcess containers: Two major features were added prior to moving to stable: the ability to run as local user accounts, and a simplified method of accessing volume mounts. To learn more, read Create a Windows HostProcess Pod . HostProcess containers in action Kubernetes SIG Windows has been busy putting HostProcess containers to use - even before GA! They've been very excited to use HostProcess containers for a number of important activities that were a pain to perform in the past. Here are just a few of the many use use cases with example deployments: CNI solutions and kube-proxy windows-exporter csi-proxy Windows-debug container ETW event streaming How do I use it? A HostProcess container can be built using any base image of your choosing, however, for convenience we have created a HostProcess container base image . This image is only a few KB in size and does not inherit any of the same compatibility requirements as regular Windows server containers which allows it to run on any Windows server version. To use that Microsoft image, put this in your Dockerfile : FROM mcr.microsoft.com/oss/kubernetes/windows-host-process-containers-base-image:v1.0.0 You can run HostProcess containers from within a HostProcess Pod . To get started with running Windows containers, see the general guidance for deploying Windows nodes . If you have a compatible node (for example: Windows as the operating system with containerd v1.7 or later as the container runtime), you can deploy a Pod with one or more HostProcess containers. See the Create a Windows HostProcess Pod - Prerequisites for more information. Please note that within a Pod, you can't mix HostProcess containers with normal Windows containers. How can I learn more? Work through Create a Windows HostProcess Pod Read about Kubernetes Pod Security Standards and Pod Security Admission Read the enhancement proposal Windows Privileged Containers and Host Networking Mode (KEP-1981) Watch the Windows HostProcess for Configuration and Beyond KubeCon NA 2022 talk How do I get involved? Get involved with SIG Windows to contribute!

Splits between U.S. Department of Justice prosecutors are delaying the conclusion of a long-running criminal investigation into the world's largest cryptocurrency exchange Binance, four people familiar with the matter have told Reuters.

Author: Sascha Grunert The Kubernetes Special Interest Group (SIG) Release is proud to announce that we are digitally signing all release artifacts, and that this aspect of Kubernetes has now reached beta . Signing artifacts provides end users a chance to verify the integrity of the downloaded resource. It allows to mitigate man-in-the-middle attacks directly on the client side and therefore ensures the trustfulness of the remote serving the artifacts. The overall goal of out past work was to define the used tooling for signing all Kubernetes related artifacts as well as providing a standard signing process for related projects (for example for those in kubernetes-sigs ). We already signed all officially released container images (from Kubernetes v1.24 onwards). Image signing was alpha for v1.24 and v1.25. For v1.26, we've added all binary artifacts to the signing process as well! This means that now all client, server and source tarballs , binary artifacts , Software Bills of Material (SBOMs) as well as the build provenance will be signed using cosign . Technically speaking, we now ship additional *.sig (signature) and *.cert (certificate) files side by side to the artifacts for verifying their integrity. To verify an artifact, for example kubectl , you can download the signature and certificate alongside with the binary. I use the release candidate rc.1 of v1.26 for demonstration purposes because the final has not been released yet: curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl -o kubectl curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.sig -o kubectl.sig curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.cert -o kubectl.cert Then you can verify kubectl using cosign : COSIGN_EXPERIMENTAL = 1 cosign verify-blob kubectl --signature kubectl.sig --certificate kubectl.cert tlog entry verified with uuid: 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 index: 8173886 Verified OK The UUID can be used to query the rekor transparency log: rekor-cli get --uuid 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d Index: 8173886 IntegratedTime: 2022-11-30T18:59:07Z UUID: 24296fb24b8ad77a5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 Body: { "HashedRekordObj": { "data": { "hash": { "algorithm": "sha256", "value": "982dfe7eb5c27120de6262d30fa3e8029bc1da9e632ce70570e9c921d2851fc2" } }, "signature": { "content": "MEQCIH0e1/0svxMoLzjeyhAaLFSHy5ZaYy0/2iQl2t3E0Pj4AiBsWmwjfLzrVyp9/v1sy70Q+FHE8miauOOVkAW2lTYVug==", "publicKey": { "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN2akNDQWthZ0F3SUJBZ0lVRldab0pLSUlFWkp3LzdsRkFrSVE2SHBQdi93d0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpJeE1UTXdNVGcxT1RBMldoY05Nakl4TVRNd01Ua3dPVEEyV2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVDT3h5OXBwTFZzcVFPdHJ6RFgveTRtTHZSeU1scW9sTzBrS0EKTlJDM3U3bjMreHorYkhvWVkvMUNNRHpJQjBhRTA3NkR4ZWVaSkhVaWFjUXU4a0dDNktPQ0FXVXdnZ0ZoTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVV5SmwxCkNlLzIzNGJmREJZQ2NzbXkreG5qdnpjd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d1FnWURWUjBSQVFIL0JEZ3dOb0UwYTNKbGJDMXpkR0ZuYVc1blFHczRjeTF5Wld4bGJtY3RjSEp2WkM1cApZVzB1WjNObGNuWnBZMlZoWTJOdmRXNTBMbU52YlRBcEJnb3JCZ0VFQVlPL01BRUJCQnRvZEhSd2N6b3ZMMkZqClkyOTFiblJ6TG1kdmIyZHNaUzVqYjIwd2dZb0dDaXNHQVFRQjFua0NCQUlFZkFSNkFIZ0FkZ0RkUFRCcXhzY1IKTW1NWkhoeVpaemNDb2twZXVONDhyZitIaW5LQUx5bnVqZ0FBQVlUSjZDdlJBQUFFQXdCSE1FVUNJRXI4T1NIUQp5a25jRFZpNEJySklXMFJHS0pqNkQyTXFGdkFMb0I5SmNycXlBaUVBNW4xZ283cmQ2U3ZVeXNxeldhMUdudGZKCllTQnVTZHF1akVySFlMQTUrZTR3Q2dZSUtvWkl6ajBFQXdNRFpnQXdZd0l2Tlhub3pyS0pWVWFESTFiNUlqa1oKUWJJbDhvcmlMQ1M4MFJhcUlBSlJhRHNCNTFUeU9iYTdWcGVYdThuTHNjVUNNREU4ZmpPZzBBc3ZzSXp2azNRUQo0c3RCTkQrdTRVV1UrcjhYY0VxS0YwNGJjTFQwWEcyOHZGQjRCT2x6R204K093PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" } } } } The HashedRekordObj.signature.content should match the content of the file kubectl.sig and HashedRekordObj.signature.publicKey.content should be identical with the contents of kubectl.cert . It is also possible to specify the remote certificate and signature locations without downloading them: COSIGN_EXPERIMENTAL = 1 cosign verify-blob kubectl \ --signature https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.sig \ --certificate https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.cert tlog entry verified with uuid: 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 index: 8173886 Verified OK All of the mentioned steps as well as how to verify container images are outlined in the official documentation about how to Verify Signed Kubernetes Artifacts . In one of the next upcoming Kubernetes releases we will working making the global story more mature by ensuring that truly all Kubernetes artifacts are signed. Beside that, we are considering using Kubernetes owned infrastructure for the signing (root trust) and verification (transparency log) process. Getting involved If you're interested in contributing to SIG Release, then consider applying for the upcoming v1.27 shadowing program (watch for the announcement on k-dev ) or join our weekly meeting to say hi . We're looking forward to making even more of those awesome changes for future Kubernetes releases. For example, we're working on the SLSA Level 3 Compliance in the Kubernetes Release Process or the Renaming of the kubernetes/kubernetes default branch name to main . Thank you for reading this blog post! I'd like to use this opportunity to give all involved SIG Release folks a special shout-out for shipping this feature in time! Feel free to reach out to us by using the SIG Release mailing list or the #sig-release Slack channel. Additional resources Signing Release Artifacts Enhancement Proposal

Authors: Chris Short , Frederico Muñoz In my work in the Kubernetes world, I look up a label or Prow command often. The systems behind the scenes (Prow and Tide ) are here to help Kubernetes Contributors get stuff done. Labeling which SIG, WG, or subproject is as important as the issue or PR having someone assigned. To quote the docs , “Tide is a Prow component for managing a pool of GitHub PRs that match a given set of criteria. It will automatically retest PRs that meet the criteria (‘tide comes in’) and automatically merge them when they have up-to-date passing test results (‘tide goes out’).” What actually prompted this article is the awesomely amazing folks on the Contributor Comms team saying, “I need to squash my commits and push that.” Which immediately made me remember the wonder of the Tide label: tide/merge-method-squash . Why is this helpful Contributing to Kubernetes will, most of the time, involve some kind of git-based action, specifically on the Kubernetes GitHub. This can be an obstacle to those less exposed to git and/or GitHub, and is especially noticeable when we’re dealing with non-code contributions (documentation, blog posts, etc.). When a contributor submits something, it will generally be through a pull request . When it comes to how the change will go from request to approval, there are a number of considerations that must be made, such as: How should we request reviews? How do we assign the request to a specific SIG? How do we approve things while making it public and easily traceable? How to merge a contribution without carrying all the commit messages that were created during the review? These are some of the main tasks in which Tide will help, allowing us to use the GitHub interface for these tasks (and more), making the actions more visible to the community (since they are visible as plain comments in the GitHub discussion), and allowing us to manage contributions without necessarily having to clone git repositories or having to manually issue git commands. Back to squashing One of the most common examples, and getting back to my initial one, is squashing commits: if someone makes a change in a PR, there will likely be reviews and changes, and each one of them will add a new commit message. If left like this, the PR will add to the main branch all the commit messages created during the review process, which will make the history of the main branch less readable: instead of a single informative description about a specific unit of work , it will contain multiple commit messages that, out of the original context of the PR, will not be very helpful. To avoid this, we can squash the commit messages to keep just one of them (usually, the first one): the changes will still be visible for anyone reading the PR, but they will appear as a single commit to the main branch. This can be done through git , and a cursory read of how it’s done will not be obvious to someone relatively new to git! Is there a way to avoid cloning the repository (or PR), issuing git commands locally, and pushing the changes? There is, with Tide. Squashing your commits is a label away and the tooling will do the rest. To do this on your PR you’ll need to comment with the following: /label tide/merge-method-squash This will: Trigger Tide to squash the messages prior to merging. As a secondary effect, make your action clearly visible in the discussion section of the PR. This use of Tide is one of the most useful when submitting changes that undergo changes during the PR discussion, since it automates something to do The Right Thing (TM). There’s often nothing better than an example, so let’s take a look at this proposed change to the Kubernetes website , on the topic of the dockershim removal FAQ. The initial commit is followed by several others , a result of the conversation and proposed reviews. The result of all those changes is merged as a single commit, with the commit message retaining the title of the very first commit done, and the commit description being the aggregate of all the commits done in the PR. This was achieved by using /label tide/merge-method-squash in a comment , and did away with the need to manually rebase and/or squash using git : everything was possible through the GitHub interface. Assignment, review, approval. Another area in which Prow and Tide are very useful is in dealing with assignments, reviews, and approvals. Starting with assignment , the need to assign a PR to someone is very common. There are ways to do it through the GitHub interface, but using Prow commands, as mentioned before, makes the actions more visible and explicitly trigger the automation mechanism. Using /assign in a comment will assign the PR to yourself, or reassign it to someone else. Asking for reviews is another very common task: with Prow it’s just a /cc @foo @bar @baz away, and this can be directly added in the initial PR description, or in any subsequent comment. Approving a PR is one area in which making the process easily visible is very important, and, unsurprisingly, we can use /lgtm (looks good to me ) to publicly state our agreement, and at the same time trigger the automated processes that will, hopefully, result in the merging of the contribution. Using lgtm adds (or, if using /lgtm cancel , removes) the lgtm label, while using /approve will approve the PR for merging (and can only be used by those with the necessary authorization). To summarize, /assign makes it public that an assignment as been made (I use it often when I need to assign an issue to myself), and by who; /lgtm makes it clear from the comments that a review was made and, automatically, adds the lgtm label which is required for approval, and /approve approves the PR for merging. An example of many of these is this update to the Kubernetes Community site : we can see how additional reviewers were added with /cc , and following the discussion and changes, both the /lgtm and /approve commands are used to trigger the merging. More information on the review and approval cycle can be found in the documentation , which also explains in more detail when should certain commands be used, and by who. More about Prow and Tide The previous examples are some of the most commonly used, but Prow and Tide provide a lot more. These two pages document all the functionality available to Kubernetes contributors (either through labels or Prow): Prow Command Help test-infra/label_sync/labels.md Labels are most commonly applied by using an associated command (e.g. /lgtm , instead of /label lgtm ): only when no such command exists are labels applied directly with the label command; some of my more often used commands and labels: /assign (using it without adding a name assigns yourself) /honk /(woof|bark|this-is-{fine|not-fine|unbearable}) /remove-lifecycle stale (when issues aren’t touched for a period of time they’re marked stale) /shrug /area contributor-comms (You can use this to flag down the contributor communications team for reviews, comments on any issue, feedback, etc.) /label size/X (Sizes are assigned automatically based on the number of lines changed in the PR) /hold (This one is used for many things; if your PR is a work in progress, needs to be held to a certain date, etc.) /lgtm (Adds or removes the ‘lgtm’ label which is typically used to gate merging) /approve (Approves a pull request; must be done by someone in the repo’s OWNERS file) More advanced usage What if you need a label that isn’t available on a certain GitHub repository? I’m glad you asked! This PR demonstrates how to add labels to a repo: https://github.com/kubernetes/test-infra/pull/24315 . You’ll need to update the labels.yaml file (the configuration) and the labels.md file (documentation). This is why the label_sync tool, along with the logic Prow and Tide, simplify GitHub-based processes: they allow the automation of common actions without necessarily having to leave the web-based GitHub interface. label_sync ensures that labels are applied uniformly across repositories. I’ve done this once in five years of contributing. But, it’s good to write it down as it’s something that isn’t as trivial as you think because of the importance of the label_sync tooling. These are a handful of the commands and labels I enjoy. I’m sure there are many others that are helpful to folks. With that in mind, see if there’s something you can benefit from in these resources. They are there to make working on Kubernetes a better experience. If you think there’s some functionality missing, I’d invite you to drop a Slack message in SIG ContribEx or SIG Testing to discuss. Huge shoutout : To the folks that keep these systems humming along for the Kubernetes community. Couldn’t do it without y’all.

U.S. chipmaker Broadcom is set to face a setback in its $61 billion bid for cloud computing company VMware with EU antitrust regulators poised to open a full-scale investigation into the deal, people familiar with the matter said.

Bullying in the workplace can take many forms and come from many directions, including “upward” — that is, bullying of managers by people who report to them. Upward bullying often starts with covert behaviors such as withholding information and subtle gaslighting. After eroding some of the bullied supervisor’s legitimate authority and psychological resources, bullies escalate to spreading rumors, circumventing, and insubordination, further undermining the target’s position and well-being. Typically, bullying by subordinates is enabled by support from the management one or more levels above the targeted supervisor. The authors present several strategies for targeted managers to protect their mental health, their unit’s productivity, and their career, plus strategies for bullying targets’ managers.

Imagine walking into a room at night, turning out all the lights and closing the shades. Yet an eerie glow comes from the walls, ceiling, and floor. The faint light is barely enough to see your hands ...

Suppressing memories using an “amnesic shadow” could someday lead to a gentler therapy for post-traumatic stress disorder

Weirdly, any recent work on The Line doesn’t show up on Google Maps. But we got the images anyway.

Answer (1 of 2): Many projects like Folding@Home rely on the BOINC project for distributing their workloads (although Folding@Home itself apparently does not). You can peruse the BOINC projects here: Choosing BOINC projects Why not help out the search for ET with SETI@home?

You are not “spoiled” for wanting rest, there is no virtue in exhaustion, so much research abt working conditions shows that rest & breaks = more productivity, aaand even if it didn’t, this is your life, it is precious, you deserve better.— Kirin Khan (@kirinjaan) December 10, 2022

The layoffs "impacted female employees to a much greater extent than male employees," the lawsuit alleges.

Authors : Kubernetes 1.26 Release Team It's with immense joy that we announce the release of Kubernetes v1.26! This release includes a total of 37 enhancements: eleven of them are graduating to Stable, ten are graduating to Beta, and sixteen of them are entering Alpha. We also have twelve features being deprecated or removed, three of which we better detail in this announcement. Release theme and logo Kubernetes 1.26: Electrifying The theme for Kubernetes v1.26 is Electrifying . Each Kubernetes release is the result of the coordinated effort of dedicated volunteers, and only made possible due to the use of a diverse and complex set of computing resources, spread out through multiple datacenters and regions worldwide. The end result of a release - the binaries, the image containers, the documentation - are then deployed on a growing number of personal, on-premises, and cloud computing resources. In this release we want to recognise the importance of all these building blocks on which Kubernetes is developed and used, while at the same time raising awareness on the importance of taking the energy consumption footprint into account: environmental sustainability is an inescapable concern of creators and users of any software solution, and the environmental footprint of sofware, like Kubernetes, an area which we believe will play a significant role in future releases. As a community, we always work to make each new release process better than before (in this release, we have started to use Projects for tracking enhancements , for example). If v1.24 "Stargazer" had us looking upwards, to what is possible when our community comes together , and v1.25 "Combiner" what the combined efforts of our community are capable of , this v1.26 "Electrifying" is also dedicated to all of those whose individual motion, integrated into the release flow, made all of this possible. Major themes Kubernetes v1.26 is composed of many changes, brought to you by a worldwide team of volunteers. For this release, we have identified several major themes. Change in container image registry In the previous release, Kubernetes changed the container registry , allowing the spread of the load across multiple Cloud Providers and Regions, a change that reduced the reliance on a single entity and provided a faster download experience for a large number of users. This release of Kubernetes is the first that is exclusively published in the new registry.k8s.io container image registry. In the (now legacy) k8s.gcr.io image registry, no container images tags for v1.26 will be published, and only tags from releases before v1.26 will continue to be updated. Refer to registry.k8s.io: faster, cheaper and Generally Available for more information on the motivation, advantages, and implications of this significant change. CRI v1alpha2 removed With the adoption of the Container Runtime Interface (CRI) and the removal of dockershim in v1.24, the CRI is the only supported and documented way through which Kubernetes interacts with different container runtimes. Each kubelet negotiates which version of CRI to use with the container runtime on that node. In the previous release, the Kubernetes project recommended using CRI version v1 , but kubelet could still negotiate the use of CRI v1alpha2 , which was deprecated. Kubernetes v1.26 drops support for CRI v1alpha2 . That removal will result in the kubelet not registering the node if the container runtime doesn't support CRI v1 . This means that containerd minor version 1.5 and older are not supported in Kubernetes 1.26; if you use containerd, you will need to upgrade to containerd version 1.6.0 or later before you upgrade that node to Kubernetes v1.26. This applies equally to any other container runtimes that only support the v1alpha2 : if that affects you, you should contact the container runtime vendor for advice or check their website for additional instructions in how to move forward. Storage improvements Following the GA of the core Container Storage Interface (CSI) Migration feature in the previous release, CSI migration is an on-going effort that we've been working on for a few releases now, and this release continues to add (and remove) features aligned with the migration's goals, as well as other improvements to Kubernetes storage. CSI migration for Azure File and vSphere graduated to stable Both the vSphere and Azure in-tree driver migration to CSI have graduated to Stable. You can find more information about them in the vSphere CSI driver and Azure File CSI driver repositories. Delegate FSGroup to CSI Driver graduated to stable This feature allows Kubernetes to supply the pod's fsGroup to the CSI driver when a volume is mounted so that the driver can utilize mount options to control volume permissions. Previously, the kubelet would always apply the fsGroup ownership and permission change to files in the volume according to the policy specified in the Pod's .spec.securityContext.fsGroupChangePolicy field. Starting with this release, CSI drivers have the option to apply the fsGroup settings during attach or mount time of the volumes. In-tree GlusterFS driver removal Already deprecated in the v1.25 release, the in-tree GlusterFS driver was removed in this release. In-tree OpenStack Cinder driver removal This release removed the deprecated in-tree storage integration for OpenStack (the cinder volume type). You should migrate to external cloud provider and CSI driver from https://github.com/kubernetes/cloud-provider-openstack instead. For more information, visit Cinder in-tree to CSI driver migration . Signing Kubernetes release artifacts graduates to beta Introduced in Kubernetes v1.24, this feature constitutes a significant milestone in improving the security of the Kubernetes release process. All release artifacts are signed keyless using cosign , and both binary artifacts and images can be verified . Support for Windows privileged containers graduates to stable Privileged container support allows containers to run with similar access to the host as processes that run on the host directly. Support for this feature in Windows nodes, called HostProcess containers , will now graduate to Stable , enabling access to host resources (including network resources) from privileged containers. Improvements to Kubernetes metrics This release has several noteworthy improvements on metrics. Metrics framework extension graduates to alpha The metrics framework extension graduates to Alpha , and documentation is now published for every metric in the Kubernetes codebase .This enhancement adds two additional metadata fields to Kubernetes metrics: Internal and Beta , representing different stages of metric maturity. Component Health Service Level Indicators graduates to alpha Also improving on the ability to consume Kubernetes metrics, component health Service Level Indicators (SLIs) have graduated to Alpha : by enabling the ComponentSLIs feature flag there will be an additional metrics endpoint which allows the calculation of Service Level Objectives (SLOs) from raw healthcheck data converted into metric format. Feature metrics are now available Feature metrics are now available for each Kubernetes component, making it possible to track whether each active feature gate is enabled by checking the component's metric endpoint for kubernetes_feature_enabled . Dynamic Resource Allocation graduates to alpha Dynamic Resource Allocation is a new feature that puts resource scheduling in the hands of third-party developers: it offers an alternative to the limited "countable" interface for requesting access to resources (e.g. nvidia.com/gpu: 2 ), providing an API more akin to that of persistent volumes. Under the hood, it uses the Container Device Interface (CDI) to do its device injection. This feature is blocked by the DynamicResourceAllocation feature gate. CEL in Admission Control graduates to alpha This feature introduces a v1alpha1 API for validating admission policies , enabling extensible admission control via Common Expression Language expressions. Currently, custom policies are enforced via admission webhooks , which, while flexible, have a few drawbacks when compared to in-process policy enforcement. To use, enable the ValidatingAdmissionPolicy feature gate and the admissionregistration.k8s.io/v1alpha1 API via --runtime-config . Pod scheduling improvements Kubernetes v1.26 introduces some relevant enhancements to the ability to better control scheduling behavior. PodSchedulingReadiness graduates to alpha This feature introduces a .spec.schedulingGates field to Pod's API, to indicate whether the Pod is allowed to be scheduled or not . External users/controllers can use this field to hold a Pod from scheduling based on their policies and needs. NodeInclusionPolicyInPodTopologySpread graduates to beta By specifying a nodeInclusionPolicy in topologySpreadConstraints , you can control whether to take taints/tolerations into consideration when calculating Pod Topology Spread skew. Other Updates Graduations to stable This release includes a total of eleven enhancements promoted to Stable: Support for Windows privileged containers vSphere in-tree to CSI driver migration Allow Kubernetes to supply pod's fsgroup to CSI driver on mount Azure file in-tree to CSI driver migration Job tracking without lingering Pods Service Internal Traffic Policy Kubelet Credential Provider Support of mixed protocols in Services with type=LoadBalancer Reserve Service IP Ranges For Dynamic and Static IP Allocation CPUManager DeviceManager Deprecations and removals 12 features were deprecated or removed from Kubernetes with this release. CRI v1alpha2 API is removed Removal of the v1beta1 flow control API group Removal of the v2beta2 HorizontalPodAutoscaler API GlusterFS plugin removed from available...