Merge pull request #38242 from sftim/merged-main-dev-1.26

 Merge main into dev-1.26 to keep in sync

OWNERS_ALIASES

@@ -1,17 +1,16 @@
 aliases:
   sig-docs-blog-owners: # Approvers for blog content
-    - onlydole
     - mrbobbytables
-    - sftim
     - nate-double-u
+    - onlydole
+    - sftim
   sig-docs-blog-reviewers: # Reviewers for blog content
     - mrbobbytables
+    - nate-double-u
     - onlydole
     - sftim
-    - nate-double-u
   sig-docs-localization-owners: # Admins for localization content
     - a-mccarthy
-    - bradtopol
     - divya-mohan0209
     - jimangel
     - kbhawkey
@@ -33,7 +32,6 @@ aliases:
     - bradtopol
     - divya-mohan0209
     - jimangel
-    - jlbutler
     - kbhawkey
     - krol3
     - natalisucks
@@ -44,15 +42,13 @@ aliases:
     - tengqm
   sig-docs-en-reviews: # PR reviews for English content
     - bradtopol
-    - daminisatya
     - divya-mohan0209
     - jimangel
     - kbhawkey
     - mehabhalodiya
     - natalisucks
     - nate-double-u
     - onlydole
-    - rajeshdeshpande02
     - reylejano
     - sftim
     - shannonxtreme
@@ -255,17 +251,19 @@ aliases:
   # authoritative source: https://git.k8s.io/sig-release/OWNERS_ALIASES
   sig-release-leads:
     - cpanato # SIG Technical Lead
-    - jeremyrickard # SIG Technical Lead
+    - jeremyrickard # SIG Chair
     - justaugustus # SIG Chair
     - puerco # SIG Technical Lead
     - saschagrunert # SIG Chair
+    - Verolop # SIG Technical Lead
   release-engineering-approvers:
-    - cpanato # Release Manager
+    - cpanato # subproject owner / Release Manager
+    - jeremyrickard # subproject owner / Release Manager
+    - justaugustus # subproject owner / Release Manager
     - palnabarun # Release Manager
-    - puerco # Release Manager
+    - puerco # subproject owner / Release Manager
     - saschagrunert # subproject owner / Release Manager
-    - justaugustus # subproject owner / Release Manager
-    - Verolop # Release Manager
+    - Verolop # subproject owner / Release Manager
     - xmudrii # Release Manager
   release-engineering-reviewers:
     - ameukam # Release Manager Associate

SECURITY_CONTACTS

@@ -11,5 +11,9 @@
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
 divya-mohan0209
-jimangel
+reylejano
 sftim
+tengqm
+onlydole
+kbhawkey
+natalisucks

content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md

@@ -4,9 +4,12 @@ title: "PodSecurityPolicy Deprecation: Past, Present, and Future"
 date: 2021-04-06
 slug: podsecuritypolicy-deprecation-past-present-and-future
 ---
-
 **Author:** Tabitha Sable (Kubernetes SIG Security)
 
+{{% pageinfo color="primary" %}}
+**Update:** *With the release of Kubernetes v1.25, PodSecurityPolicy has been removed.* *You can read more information about the removal of PodSecurityPolicy in the [Kubernetes 1.25 release notes](/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes).*
+{{% /pageinfo %}}
+
 PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably.
 
 What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes.

content/en/blog/_posts/2022-10-18-kubernetes-1.26-deprecations-and-removals.md

@@ -11,7 +11,7 @@ Change is an integral part of the Kubernetes life-cycle: as Kubernetes grows and
 
 ## The Kubernetes API Removal and Deprecation process {#k8s-api-deprecation-process}
 
-The Kubernetes project has a [well-documented deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API is one that 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 result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement.
+The Kubernetes project has a [well-documented deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API is one that 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 result in a warning being displayed. Removed APIs are no longer available in the current version, at which point 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 deprecation.
@@ -21,7 +21,7 @@ Whether an API is removed as a result of a feature graduating from beta to stabl
 
 ## A note about the removal of the CRI `v1alpha2` API and containerd 1.5 support {#cri-api-removal}
 
-Following the adoption of the [Container Runtime Interface](https://kubernetes.io/docs/concepts/architecture/cri/) (CRI) and the [removal of dockershim] in v1.24 , the CRI is the supported and documented way through which Kubernetes interacts withdifferent container runtimes. Each kubelet negotiates which version of CRI to use with the container runtime on that node.
+Following the adoption of the [Container Runtime Interface](/docs/concepts/architecture/cri/) (CRI) and the [removal of dockershim] in v1.24 , the CRI is the 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.
 
 The Kubernetes project recommends using CRI version `v1`; in Kubernetes v1.25 the kubelet can also negotiate the use of CRI `v1alpha2` (which was deprecated along at the same time as adding support for the stable `v1` interface).
 
@@ -37,11 +37,11 @@ In addition to the above, Kubernetes v1.26 is targeted to include several additi
 
 ### Removal of the `v1beta1` flow control API group
 
-The `flowcontrol.apiserver.k8s.io/v1beta1` API version of FlowSchema and PriorityLevelConfiguration [will no longer be served in v1.26](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#flowcontrol-resources-v126). Users should migrate manifests and API clients to use the `flowcontrol.apiserver.k8s.io/v1beta2` API version, available since v1.23.
+The `flowcontrol.apiserver.k8s.io/v1beta1` API version of FlowSchema and PriorityLevelConfiguration [will no longer be served in v1.26](/docs/reference/using-api/deprecation-guide/#flowcontrol-resources-v126). Users should migrate manifests and API clients to use the `flowcontrol.apiserver.k8s.io/v1beta2` API version, available since v1.23.
 
 ### Removal of the `v2beta2` HorizontalPodAutoscaler API
 
-The `autoscaling/v2beta2` API version of HorizontalPodAutoscaler [will no longer be served in v1.26](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#horizontalpodautoscaler-v126). Users should migrate manifests and API clients to use the `autoscaling/v2` API version, available since v1.23.
+The `autoscaling/v2beta2` API version of HorizontalPodAutoscaler [will no longer be served in v1.26](/docs/reference/using-api/deprecation-guide/#horizontalpodautoscaler-v126). Users should migrate manifests and API clients to use the `autoscaling/v2` API version, available since v1.23.
 
 ### Removal of in-tree credential management code
 
@@ -64,14 +64,14 @@ The `userspace` proxy mode, deprecated for over a year, is [no longer supported
 ### Removal of in-tree OpenStack cloud provider
 
 Kubernetes is switching from in-tree code for storage integrations, in favor of the Container Storage Interface (CSI).
-As part of this, Kubernetes v1.26 will remove the the deprecated in-tree storage integration for OpenStack
+As part of this, Kubernetes v1.26 will remove 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](https://github.com/kubernetes/enhancements/issues/1489).
 
 ### Removal of the GlusterFS in-tree driver
 
-The in-tree GlusterFS driver was [deprecated in v1.25](https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/#deprecations-and-removals), and will be removed from Kubernetes v1.26.
+The in-tree GlusterFS driver was [deprecated in v1.25](/blog/2022/08/23/kubernetes-v1-25-release/#deprecations-and-removals), and will be removed from Kubernetes v1.26.
 
 ### Deprecation of non-inclusive `kubectl` flag
 
@@ -91,7 +91,7 @@ Dynamic kubelet configuration was removed from the kubelet in v1.24, and will be
 
 The `--master-service-namespace` command line argument to the kube-apiserver doesn't have
 any effect, and was already informally [deprecated](https://github.com/kubernetes/kubernetes/pull/38186).
-That command line argument wil be formally marked as deprecated in v1.26, preparing for its
+That command line argument will be formally marked as deprecated in v1.26, preparing for its
 removal in a future release.
 The Kubernetes project does not expect any impact from this deprecation and removal.
 
@@ -108,7 +108,7 @@ Several unused option arguments for the `kubectl run` subcommand will be [marked
 * `--timeout`
 * `--wait`
 
-These arguments are already ignored so no impact is expected: the explicit deprecation sets a warning message and prepares the removal of the argumentsin a future release.
+These arguments are already ignored so no impact is expected: the explicit deprecation sets a warning message and prepares the removal of the arguments in a future release.
 
 ### Removal of legacy command line arguments relating to logging
 
@@ -119,7 +119,7 @@ For more information, see [Deprecate klog specific flags in Kubernetes Component
 
 ## Looking ahead {#looking-ahead}
 
-The official list of [API removals](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-27) planned for Kubernetes 1.27 includes:
+The official list of [API removals](/docs/reference/using-api/deprecation-guide/#v1-27) planned for Kubernetes 1.27 includes:
 
 * All beta versions of the CSIStorageCapacity API; specifically: `storage.k8s.io/v1beta1`
 

content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md

@@ -0,0 +1,75 @@
+---
+layout: blog
+title: "registry.k8s.io: faster, cheaper and Generally Available (GA)"
+date: 2022-11-28
+slug: registry-k8s-io-faster-cheaper-ga
+---
+
+**Authors**: Adolfo García Veytia (Chainguard), Bob Killen (Google)
+
+Starting with Kubernetes 1.25, our container image registry has changed from k8s.gcr.io to [registry.k8s.io](https://registry.k8s.io). This new registry spreads the load across multiple Cloud Providers & Regions, functioning as a sort of content delivery network (CDN) for Kubernetes container images. This change reduces the project’s reliance on a single entity and provides a faster download experience for a large number of users.
+
+## TL;DR: What you need to know about this change
+
+* Container images for Kubernetes releases from 1.25 onward are no longer published to k8s.gcr.io, only to registry.k8s.io.
+* In the upcoming December patch releases, the new registry domain default will be backported to all branches still in support (1.22, 1.23, 1.24).
+* If you run in a restricted environment and apply strict domain/IP address access policies limited to k8s.gcr.io, the __image pulls will not function__ after the migration to this new registry. For these users, the recommended method is to mirror the release images to a private registry.
+
+If you’d like to know more about why we made this change, or some potential issues you might run into, keep reading.
+
+## Why has Kubernetes changed to a different image registry?
+
+k8s.gcr.io is hosted on a custom [Google Container Registry](https://cloud.google.com/container-registry) (GCR) domain that was setup solely for the Kubernetes project. This has worked well since the inception of the project, and we thank Google for providing these resources, but today there are other cloud providers and vendors that would like to host images to provide a better experience for the people on their platforms. In addition to Google’s [renewed commitment to donate $3 million](https://www.cncf.io/google-cloud-recommits-3m-to-kubernetes/) to support the project's infrastructure, Amazon announced a matching donation during their Kubecon NA 2022 keynote in Detroit. This will provide a better experience for users (closer servers = faster downloads) and will reduce the egress bandwidth and costs from GCR at the same time. registry.k8s.io will spread the load between Google and Amazon, with other providers to follow in the future.
+
+## Why isn’t there a stable list of domains/IPs? Why can’t I restrict image pulls?
+
+registry.k8s.io is a [secure blob redirector](https://github.com/kubernetes/registry.k8s.io/blob/main/cmd/archeio/docs/request-handling.md) that connects clients to the closest cloud provider. The nature of this change means that a client pulling an image could be redirected to any one of a large number of backends. We expect the set of backends to keep changing and will only increase as more and more cloud providers and vendors come on board to help mirror the release images. 
+
+Restrictive control mechanisms like man-in-the-middle proxies or network policies that restrict access to a specific list of IPs/domains will break with this change. For these scenarios, we encourage you to mirror the release images to a local registry that you have strict control over.
+
+For more information on this policy, please see the [stability section of the registry.k8s.io documentation](https://github.com/kubernetes/registry.k8s.io#stability).
+
+## What kind of errors will I see? How will I know if I’m still using the old address?
+
+Errors may depend on what kind of container runtime you are using, and what endpoint you are routed to, but it should present as a container failing to be created with the warning `FailedCreatePodSandBox`.
+
+Below is an example error message showing a proxied deployment failing to pull due to an unknown certificate:
+
+```
+FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority
+```
+
+## I’m impacted by this change, how do I revert to the old registry address?
+
+If using the new registry domain name is not an option, you can revert to the old domain name for cluster versions less than 1.25. Keep in mind that, eventually, you will have to switch to the new registry, as new image tags will no longer be pushed to GCR.
+
+### Reverting the registry name in kubeadm
+The registry used by kubeadm to pull its images can be controlled by two methods:
+
+Setting the `--image-repository` flag. 
+
+```
+kubeadm init --image-repository=k8s.gcr.io
+```
+
+Or in [kubeadm config](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/) `ClusterConfiguration`:
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: ClusterConfiguration
+imageRepository: "k8s.gcr.io"
+```
+
+### Reverting the Registry Name in kubelet
+
+The image used by kubelet for the pod sandbox (`pause`) can be overridden by setting the `--pod-infra-container-image` flag. For example:
+
+```
+kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5
+```
+
+## Acknowledgments
+
+__Change is hard__, and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans. 
+
+Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google.