Merge pull request #45722 from chanieljdan/merged-main-dev-1.30

Merged main dev 1.30

Author: k8s-ci-robot

README-hi.md

@@ -1,6 +1,6 @@
 # कुबरनेट्स प्रलेखन
 
-[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys)
 [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
 स्वागत है! इस रिपॉजिटरी में [कुबरनेट्स वेबसाइट और दस्तावेज](https://kubernetes.io/) बनाने के लिए आवश्यक सभी संपत्तियाँ हैं। हम बहुत खुश हैं कि आप योगदान करना चाहते हैं!

README.md

@@ -20,6 +20,9 @@ To use this repository, you need the following installed locally:
 - [Hugo (Extended version)](https://gohugo.io/)
 - A container runtime, like [Docker](https://www.docker.com/).
 
+> [!NOTE]
+Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L11) file.
+
 Before you start, install the dependencies. Clone the repository and navigate to the directory:
 
 ```bash
@@ -56,8 +59,6 @@ Open up your browser to <http://localhost:1313> to view the website. As you make
 
 ## Running the website locally using Hugo
 
-Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L11) file.
-
 To install dependencies, deploy and test the site locally, run:
 
 - For macOS and Linux

content/en/blog/_posts/2022-11-04-live-and-let-live-with-kluctl-and-ssa.md

@@ -22,12 +22,12 @@ large Kubernetes deployments, composed of multiple smaller parts
 
 To get a basic understanding of Kluctl, I suggest to visit the [kluctl.io](https://kluctl.io)
 website and read through the documentation and tutorials, for example the 
-[microservices demo tutorial](https://kluctl.io/docs/guides/tutorials/microservices-demo/).
+[microservices demo tutorial](https://kluctl.io/docs/tutorials/microservices-demo/1-basic-project-setup/).
 As an alternative, you can watch [Hands-on Introduction to kluctl](https://www.youtube.com/watch?v=9LoYLjDjOdg)
 from the Rawkode Academy YouTube channel which shows a hands-on demo session.
 
-There is also a [Kluctl delivery scenario](https://github.com/codablock/podtato-head/tree/kluctl/delivery/kluctl)
-available in my fork of the [podtato-head](https://github.com/codablock/podtato-head) demo project.
+There is also a [Kluctl delivery scenario](https://github.com/podtato-head/podtato-head-delivery/tree/main/kluctl)
+for the [podtato-head](https://github.com/podtato-head/podtato-head) demo project.
 
 ## Live and let live
 
@@ -144,8 +144,8 @@ If the field manager is not known by Kluctl, it will check if force-applying is
 requested for that field. Force-applying can be requested in different ways:
 
 1. By passing `--force-apply` to Kluctl. This will cause ALL fields to be force-applied on conflicts.
-2. By adding the [`kluctl.io/force-apply=true`](https://kluctl.io/docs/reference/deployments/annotations/all-resources/#kluctlioforce-apply) annotation to the object in question. This will cause all fields of that object to be force-applied on conflicts.
-3. By adding the [`kluctl.io/force-apply-field=my.json.path`](https://kluctl.io/docs/reference/deployments/annotations/all-resources/#kluctlioforce-apply-field) annotation to the object in question. This causes only fields matching the JSON path to be force-applied on conflicts.
+2. By adding the [`kluctl.io/force-apply=true`](https://kluctl.io/docs/kluctl/deployments/annotations/all-resources/#kluctlioforce-apply) annotation to the object in question. This will cause all fields of that object to be force-applied on conflicts.
+3. By adding the [`kluctl.io/force-apply-field=my.json.path`](https://kluctl.io/docs/kluctl/deployments/annotations/all-resources/#kluctlioforce-apply-field) annotation to the object in question. This causes only fields matching the JSON path to be force-applied on conflicts.
 
 Marking a field to be force-applied is required whenever some other actor is
 known to erroneously claim fields (the ECK operator does this to the nodeSets

content/en/blog/_posts/2023-08-15-pkgs-k8s-io-introduction.md

@@ -18,41 +18,52 @@ This blog post contains information about these new package repositories,
 what does it mean to you as an end user, and how to migrate to the new
 repositories.
 
-**ℹ️  Update (January 12, 2024):** the _**legacy Google-hosted repositories are going
-away in January 2024.**_
+**ℹ️ Update (March 26, 2024): _the legacy Google-hosted repositories went
+away on March 4, 2024. It's not possible to install Kubernetes packages from
+the legacy Google-hosted package repositories any longer._**
 Check out [the deprecation announcement](/blog/2023/08/31/legacy-package-repository-deprecation/)
 for more details about this change.
 
+
 ## What you need to know about the new package repositories?
 
-_(updated on January 12, 2024)_
+_(updated on January 12, 2024 and March 26, 2024)_
 
 - This is an **opt-in change**; you're required to manually migrate from the
   Google-hosted repository to the Kubernetes community-owned repositories.
   See [how to migrate](#how-to-migrate) later in this announcement for migration information
   and instructions.
-- **The legacy Google-hosted package repositories are going away in January 2024.** These repositories
-  have been **deprecated as of August 31, 2023**, and **frozen as of September 13, 2023**.
+- **The legacy Google-hosted package repositories went away on March 4, 2024. It's not possible
+  to install Kubernetes packages from the legacy Google-hosted package repositories any longer.**
+  These repositories have been **deprecated as of August 31, 2023**, and **frozen as of September 13, 2023**.
   Check out the [deprecation announcement](/blog/2023/08/31/legacy-package-repository-deprecation/)
   for more details about this change.
+- ~~**The legacy Google-hosted package repositories are going away in January 2024.** These repositories
+  have been **deprecated as of August 31, 2023**, and **frozen as of September 13, 2023**.
+  Check out the [deprecation announcement](/blog/2023/08/31/legacy-package-repository-deprecation/)
+  for more details about this change.~~
 - ~~The existing packages in the legacy repositories will be available for the foreseeable future.
   However, the Kubernetes project can't provide any guarantees on how long is that going to be.
   The deprecated legacy repositories, and their contents, might be removed at any time in the future
-  and without a further notice period.~~ **The legacy package repositories are going away in
-  January 2024.**
+  and without a further notice period. **The legacy package repositories are going away in
+  January 2024.**~~ **The legacy Google-hosted package repositories went away on March 4, 2024.**
 - Given that no new releases will be published to the legacy repositories after
   the September 13, 2023 cut-off point, you will not be able to upgrade to any patch or minor
   release made from that date onwards if you don't migrate to the new Kubernetes package repositories.
-  That said, we recommend migrating to the new Kubernetes package repositories **as soon as possible**.
-- The new Kubernetes package repositories contain packages beginning with those
+  ~~That said, we recommend migrating to the new Kubernetes package repositories **as soon as possible**.~~
+  Migrating to the new Kubernetes package repositories is required to consume the official Kubernetes
+  packages.
+- **The new Kubernetes package repositories contain packages beginning with those
   Kubernetes versions that were still under support when the community took
   over the package builds. This means that the new package repositories have Linux packages for all
-  Kubernetes releases starting with v1.24.0.
+  Kubernetes releases starting with v1.24.0.**
 - Kubernetes does not have official Linux packages available for earlier releases of Kubernetes;
   however, your Linux distribution may provide its own packages.
 - There's a dedicated package repository for each Kubernetes minor version.
   When upgrading to a different minor release, you must bear in mind that
-  the package repository details also change.
+  the package repository details also change. Check out
+  [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/)
+  guide for information about steps that you need to take upon upgrading the Kubernetes minor version.
 
 ## Why are we introducing new package repositories?
 
@@ -144,13 +155,20 @@ There are three significant differences that you should be aware of:
 
 ## Does this in any way affect existing Google-hosted repositories?
 
-The Google-hosted repository and all packages published to it will continue
+_(updated on March 26, 2024)_
+
+**The legacy Google-hosted repositories went away on March 4, 2024. It's not possible to
+install Kubernetes packages from the legacy Google-hosted package repositories any longer.**
+Check out [the deprecation announcement](/blog/2023/08/31/legacy-package-repository-deprecation/)
+for more details about this change.
+
+~~The Google-hosted repository and all packages published to it will continue
 working in the same way as before. There are no changes in how we build and
 publish packages to the Google-hosted repository, all newly-introduced changes
-are only affecting packages publish to the community-owned repositories.
+are only affecting packages publish to the community-owned repositories.~~
 
-However, as mentioned at the beginning of this blog post, we plan to stop
-publishing packages to the Google-hosted repository in the future.
+~~However, as mentioned at the beginning of this blog post, we plan to stop
+publishing packages to the Google-hosted repository in the future.~~
 
 ## How to migrate to the Kubernetes community-owned repositories? {#how-to-migrate}
 
@@ -173,7 +191,7 @@ publishing packages to the Google-hosted repository in the future.
    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    ```
 
-_Update: In releases older than Debian 12 and Ubuntu 22.04, the folder `/etc/apt/keyrings` does not exist by default, and it should be created before the curl command._
+    _Update: In releases older than Debian 12 and Ubuntu 22.04, the folder `/etc/apt/keyrings` does not exist by default, and it should be created before the curl command._
 
 3. Update the `apt` package index:
 
@@ -200,11 +218,28 @@ _Update: In releases older than Debian 12 and Ubuntu 22.04, the folder `/etc/apt
    EOF
    ```
 
+## Where can I get packages for Kubernetes versions prior to v1.24.0?
+
+_(updated on March 26, 2024)_
+
+For Kubernetes v1.24 and onwards, Linux packages of Kubernetes components are available for
+download via the official Kubernetes package repositories. Kubernetes does not publish any
+software packages for releases of Kubernetes older than v1.24.0; however, your Linux
+distribution may provide its own packages. Alternatively, you can directly download binaries
+instead of using packages. As an example, see `Without a package manager` instructions in
+["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)
+document.
+
 ## Can I rollback to the Google-hosted repository after migrating to the Kubernetes repositories?
 
-In general, yes. Just do the same steps as when migrating, but use parameters
+_(updated on March 26, 2024)_
+
+**The legacy Google-hosted repositories went away on March 4, 2024 and therefore it's not possible
+to rollback to the legacy Google-hosted repositories any longer.**
+
+~~In general, yes. Just do the same steps as when migrating, but use parameters
 for the Google-hosted repository. You can find those parameters in a document
-like ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
+like ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).~~
 
 ## Why isn’t there a stable list of domains/IPs? Why can’t I restrict package downloads?
 

content/en/blog/_posts/2023-08-31-legacy-package-repository-deprecation/index.md

@@ -24,6 +24,10 @@ the repositories as of **September 13, 2023**.
 Please continue reading in order to learn what does this mean for you as an user or
 distributor, and what steps you may need to take.
 
+**ℹ️ Update (March 26, 2024): _the legacy Google-hosted repositories went
+away on March 4, 2024. It's not possible to install Kubernetes packages from
+the legacy Google-hosted package repositories any longer._**
+
 ## How does this affect me as a Kubernetes end user?
 
 This change affects users **directly installing upstream versions of Kubernetes**,
@@ -72,6 +76,8 @@ possible and inform your users about this change and what steps they need to tak
 
 <!-- note to maintainers - the trailing whitespace is significant -->
 
+_(updated on March 26, 2024)_
+
 - **15th August 2023:**  
   Kubernetes announces a new, community-managed source for Linux software packages of Kubernetes components
 - **31st August 2023:**  
@@ -81,6 +87,11 @@ possible and inform your users about this change and what steps they need to tak
   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.
+- **12th January 2024:**  
+  Kubernetes announced intentions to remove the legacy package repositories in January 2024
+- **4th March 2024:**  
+  The legacy package repositories have been removed. It's not possible to install Kubernetes packages from
+  the legacy package repositories any longer
 
 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 and
@@ -107,15 +118,20 @@ distribution may provide its own packages.
 
 ## Can I continue to use the legacy package repositories?
 
+_(updated on March 26, 2024)_
+
+**The legacy Google-hosted repositories went away on March 4, 2024. It's not possible
+to install Kubernetes packages from the legacy Google-hosted package repositories any
+longer.**
+
 ~~The existing packages in the legacy repositories will be available for the foreseeable
 future. However, the Kubernetes project can't provide _any_ guarantees on how long
 is that going to be. The deprecated legacy repositories, and their contents, might
 be removed at any time in the future and without a further notice period.~~
 
-**UPDATE**: The legacy packages are expected to go away by the end of February 2024.
-
-The Kubernetes project **strongly recommends** migrating to the new community-owned
-repositories **as soon as possible**.
+~~The Kubernetes project **strongly recommends** migrating to the new community-owned
+repositories **as soon as possible**.~~ Migrating to the new package repositories is
+required to consume the official Kubernetes packages.
 
 Given that no new releases will be published to the legacy repositories **after the September 13, 2023**
 cut-off point, **you will not be able to upgrade to any patch or minor release made from that date onwards.**