Merge pull request #7484 from sbueringer/pr-clarify-image-migration

📖 migration-doc: clarify instructions to use new registry in published components yaml

Author: k8s-ci-robot

docs/book/src/developer/providers/v1.2-to-v1.3.md

@@ -45,6 +45,8 @@ The default value is 0, meaning that the volume can be detached without any time
 
 ### Other
 
+- The Kubernetes default registry has been changed from `k8s.gcr.io` to `registry.k8s.io`. Kubernetes image promotion currently publishes to both registries. Please
+  consider publishing manifests which reference the controller images from the new registry (for reference [Cluster API PR](https://github.com/kubernetes-sigs/cluster-api/pull/7478)).
 - e2e tests are upgraded to use Ginkgo v2 (v2.2.0) and Gomega v1.20.1. Providers who use the test framework from this release will also need to upgrade, because Ginkgo v2 can't be imported alongside v1. Please see the [Ginkgo upgrade guide](https://onsi.github.io/ginkgo/MIGRATING_TO_V2), and note:
   * the default test timeout has been [changed to 1h](https://onsi.github.io/ginkgo/MIGRATING_TO_V2#timeout-behavior)
   * the `--junit-report` argument [replaces JUnit custom reporter](https://onsi.github.io/ginkgo/MIGRATING_TO_V2#improved-reporting-infrastructure) code
@@ -64,4 +66,3 @@ The default value is 0, meaning that the volume can be detached without any time
   The variable `SkipUpgrade` could be set to revert to the old behaviour by making use of the `KUBERNETES_VERSION` variable and skipping the kubernetes upgrade.
 - cert-manager upgraded from v1.9.1 to v1.10.0.
 - Machine `providerID` is now being strictly checked for equality when compared against Kubernetes node `providerID` data. This is the expected criteria for correlating a Cluster API machine to its corresponding Kubernetes node, but historically this comparison was not strict, and instead compared only against the `ID` substring part of the full `providerID` string. Because different providers construct `providerID` strings differently, the `ID` substring is not uniformly defined and implemented across providers, and thus the existing `providerID` equality can not guarantee the correct Machine-Node correlation. It is very unlikely that this new behavior will break existing providers, but FYI: if strict `providerID` equality will degrade expected behaviors, you may need to update your provider implementation prior to adopting Cluster API v1.3.
-- Default registry has changed. From now on new images will be published to `registry.k8s.io` instead of `k8s.gcr.io`.