Merge main into dev-1.34 to keep in sync

Author: rashansmith

assets/js/banner-dismiss.js

@@ -1,45 +1,53 @@
-$(document).ready(function() {
-  function setCookie(name, value, days) {
-    let expires = "";
-    let date = new Date(); // Create a new Date object
-    let dateToSecond = 24 * 60 * 60 * 1000;
-
-    if (days) {
-      date.setTime(date.getTime() + days * dateToSecond); // Modify the existing Date object
-      expires = "; expires=" + date.toUTCString();
-    }
-
-    document.cookie = name + "=" + value + expires + "; path=/";
-  }
-
-  function getCookie(name) {
-    let matches = document.cookie.match(new RegExp(
-      "(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"
-    ));
-    return matches ? "true" : undefined;
-  }
-
-  /* Check the presence of a cookie */
-  let announcement = document.querySelector("#announcement");
+$(document).ready(function() {
+  function setCookie(name, value, days) {
+    let expires = "";
+    let date = new Date(); // Create a new Date object
+    let dateToSecond = 24 * 60 * 60 * 1000;
+
+    if (days) {
+      date.setTime(date.getTime() + days * dateToSecond); // Modify the existing Date object
+      expires = "; expires=" + date.toUTCString();
+    }
+
+    document.cookie = name + "=" + value + expires + "; path=/";
+  }
+
+  function getCookie(name) {
+    let matches = document.cookie.match(new RegExp(
+      "(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"
+    ));
+    return matches ? "true" : undefined;
+  }
+
+  function getTokenName() {
+    let announcement_name_rewritten = announcement.getAttribute('data-announcement-name').replace(/\s/g, '_');
+    let token = 'announcement_ack_'+announcement_name_rewritten; // Generate the unique token for this announcement
+    return token;
+  }
+
+  /* Check the presence of a cookie */
+  let announcement = document.querySelector("#announcement");
   if (announcement) {
-    let token = `announcement_ack_${announcement.getAttribute('data-announcement-name').replace(/\s/g, '_')}`; // Generate the unique token for announcement
-    let acknowledged = getCookie(token);
+    let announcement_name_rewritten = announcement.getAttribute('data-announcement-name').replace(/\s/g, '_');
+    let tokenName = getTokenName();
+    let acknowledged = getCookie(tokenName);
     if (acknowledged === "true") {
       announcement.remove(); // Remove the announcement if the cookie is set
     }
     else {
       announcement.classList.add('display-announcement') // Display the announcement if the cookie is not set
     }
   }
-
-  /* Driver code to set the cookie */
-  let button = document.querySelector('#banner-dismiss');
+
+  /* Driver code to set the cookie */
+  let button = document.querySelector('#banner-dismiss');
   if (button) {
+    let tokenName = getTokenName();
     button.removeAttribute('style');
     button.addEventListener('click', function() {
-      setCookie(token, "true",
+      setCookie(tokenName, "true",
       button.getAttribute('data-ttl')); // Set a cookie with time to live parameter
       announcement.remove();
     });
   }
-});
+});

content/en/blog/_posts/2025-08-07-introducing-the-headlamp-ai-assistant/index.md

@@ -0,0 +1,101 @@
+---
+layout: blog
+title: "Introducing Headlamp AI Assistant"
+date: 2025-08-07T20:00:00+01:00
+slug: introducing-headlamp-ai-assistant
+author: >
+  Joaquim Rocha (Microsoft)
+canonicalUrl: "https://headlamp.dev/blog/2025/08/07/introducing-the-headlamp-ai-assistant"
+---
+
+_This announcement originally [appeared](https://headlamp.dev/blog/2025/08/07/introducing-the-headlamp-ai-assistant) on the Headlamp blog._
+
+To simplify Kubernetes management and troubleshooting, we're thrilled to
+introduce [Headlamp AI Assistant](https://github.com/headlamp-k8s/plugins/tree/main/ai-assistant#readme): a powerful new plugin for Headlamp that helps
+you understand and operate your Kubernetes clusters and applications with
+greater clarity and ease.
+
+Whether you're a seasoned engineer or just getting started, the AI Assistant offers:
+* **Fast time to value:** Ask questions like _"Is my application healthy?"_ or
+  _"How can I fix this?"_ without needing deep Kubernetes knowledge.
+* **Deep insights:** Start with high-level queries and dig deeper with prompts
+  like _"List all the problematic pods"_ or _"How can I fix this pod?"_
+* **Focused & relevant:** Ask questions in the context of what you're viewing
+  in the UI, such as _"What's wrong here?"_
+* **Action-oriented:** Let the AI take action for you, like _"Restart that
+  deployment"_, with your permission.
+
+Here is a demo of the AI Assistant in action as it helps troubleshoot an
+application running with issues in a Kubernetes cluster:
+
+{{< youtube id="GzXkUuCTcd4" title="Headlamp AI Assistant" class="youtube-quote-sm" >}}
+
+## Hopping on the AI train
+
+Large Language Models (LLMs) have transformed not just how we access data but
+also how we interact with it. The rise of tools like ChatGPT opened a world of
+possibilities, inspiring a wave of new applications. Asking questions or giving
+commands in natural language is intuitive, especially for users who aren't deeply
+technical. Now everyone can quickly ask how to do X or Y, without feeling awkward
+or having to traverse pages and pages of documentation like before.
+
+Therefore, Headlamp AI Assistant brings a conversational UI to [Headlamp](https://headlamp.dev),
+powered by LLMs that Headlamp users can configure with their own API keys.
+It is available as a Headlamp plugin, making it easy to integrate into your
+existing setup. Users can enable it by installing the plugin and configuring
+it with their own LLM API keys, giving them control over which model powers
+the assistant. Once enabled, the assistant becomes part of the Headlamp UI,
+ready to respond to contextual queries and perform actions directly from the
+interface.
+
+## Context is everything
+
+As expected, the AI Assistant is focused on helping users with Kubernetes
+concepts. Yet, while there is a lot of value in responding to Kubernetes
+related questions from Headlamp's UI, we believe that the great benefit of such
+an integration is when it can use the context of what the user is experiencing
+in an application. So, the Headlamp AI Assistant knows what you're currently
+viewing in Headlamp, and this makes the interaction feel more like working
+with a human assistant.
+
+For example, if a pod is failing, users can simply ask _"What's wrong here?"_
+and the AI Assistant will respond with the root cause, like a missing
+environment variable or a typo in the image name. Follow-up prompts like
+_"How can I fix this?"_ allow the AI Assistant to suggest a fix, streamlining
+what used to take multiple steps into a quick, conversational flow.
+
+Sharing the context from Headlamp is not a trivial task though, so it's
+something we will keep working on perfecting.
+
+## Tools
+
+Context from the UI is helpful, but sometimes additional capabilities are
+needed. If the user is viewing the pod list and wants to identify problematic
+deployments, switching views should not be necessary. To address this, the AI
+Assistant includes support for a Kubernetes tool. This allows asking questions
+like "Get me all deployments with problems" prompting the assistant to fetch
+and display relevant data from the current cluster. Likewise, if the user
+requests an action like "Restart that deployment" after the AI points out what
+deployment needs restarting, it can also do that. In case of "write"
+operations, the AI Assistant does check with the user for permission to run them.
+
+## AI Plugins
+
+Although the initial version of the AI Assistant is already useful for
+Kubernetes users, future iterations will expand its capabilities. Currently,
+the assistant supports only the Kubernetes tool, but further integration with
+Headlamp plugins is underway. Similarly, we could get richer insights for
+GitOps via the Flux plugin, monitoring through Prometheus, package management
+with Helm, and more.
+
+And of course, as the popularity of MCP grows, we are looking into how to
+integrate it as well, for a more plug-and-play fashion.
+
+## Try it out!
+
+We hope this first version of the AI Assistant helps users manage Kubernetes
+clusters more effectively and assist newcomers in navigating the learning
+curve. We invite you to try out this early version and give us your feedback.
+The AI Assistant plugin can be installed from Headlamp's Plugin Catalog in the
+desktop version, or by using the container image when deploying Headlamp.
+Stay tuned for the future versions of the Headlamp AI Assistant!

content/en/blog/_posts/2025-0X-XX-Per-Container-Restart-Policy.md

@@ -0,0 +1,204 @@
+---
+layout: blog
+title: "Kubernetes v1.34: Finer-Grained Control Over Container Restarts"
+date: 2025-0X-XX
+draft: true
+slug: kubernetes-v1-34-per-container-restart-policy
+author: >
+  [Yuan Wang](https://github.com/yuanwang04)
+---
+
+With the release of Kubernetes 1.34, a new alpha feature is introduced
+that gives you more granular control over container restarts within a Pod. This
+feature, named **Container Restart Policy and Rules**, allows you to specify a
+restart policy for each container individually, overriding the Pod's global
+restart policy. In addition, it also allows you to conditionally restart
+individual containers based on their exit codes. This feature is available
+behind the alpha feature gate `ContainerRestartRules`.
+
+This has been a long-requested feature. Let's dive into how it works and how you
+can use it.
+
+## The problem with a single restart policy
+
+Before this feature, the `restartPolicy` was set at the Pod level. This meant
+that all containers in a Pod shared the same restart policy (`Always`,
+`OnFailure`, or `Never`). While this works for many use cases, it can be
+limiting in others.
+
+For example, consider a Pod with a main application container and an init
+container that performs some initial setup. You might want the main container
+to always restart on failure, but the init container should only run once and
+never restart. With a single Pod-level restart policy, this wasn't possible.
+
+## Introducing per-container restart policies
+
+With the new `ContainerRestartRules` feature gate, you can now specify a
+`restartPolicy` for each container in your Pod's spec. You can also define
+`restartPolicyRules` to control restarts based on exit codes. This gives you
+the fine-grained control you need to handle complex scenarios.
+
+## Use cases
+
+Let's look at some real-life use cases where per-container restart policies can
+be beneficial.
+
+### In-place restarts for training jobs
+
+In ML research, it's common to orchestrate a large number of long-running AI/ML
+training workloads. In these scenarios, workload failures are unavoidable. When
+a workload fails with a retriable exit code, you want the container to restart
+quickly without rescheduling the entire Pod, which consumes a significant amount
+of time and resources. Restarting the failed container "in-place" is critical
+for better utilization of compute resources. The container should only restart
+"in-place" if it failed due to a retriable error; otherwise, the container and
+Pod should terminate and possibly be rescheduled.
+
+This can now be achieved with container-level `restartPolicyRules`. The workload
+can exit with different codes to represent retriable and non-retriable errors.
+With `restartPolicyRules`, the workload can be restarted in-place quickly, but
+only when the error is retriable.
+
+### Try-once init containers
+
+Init containers are often used to perform initialization work for the main
+container, such as setting up environments and credentials. Sometimes, you want
+the main container to always be restarted, but you don't want to retry
+initialization if it fails.
+
+With a container-level `restartPolicy`, this is now possible. The init container
+can be executed only once, and its failure would be considered a Pod failure. If
+the initialization succeeds, the main container can be always restarted.
+
+### Pods with multiple containers
+
+For Pods that run multiple containers, you might have different restart
+requirements for each container. Some containers might have a clear definition
+of success and should only be restarted on failure. Others might need to be
+always restarted.
+
+This is now possible with a container-level `restartPolicy`, allowing individual
+containers to have different restart policies.
+
+## How to use it
+
+To use this new feature, you need to enable the `ContainerRestartRules` feature
+gate on your Kubernetes cluster control-plane and worker nodes running
+Kubernetes 1.34+. Once enabled, you can specify the `restartPolicy` and
+`restartPolicyRules` fields in your container definitions.
+
+Here are some examples:
+
+### Example 1: Restarting on specific exit codes
+
+In this example, the container should restart if and only if it fails with a
+retriable error, represented by exit code 42.
+
+To achieve this, the container has `restartPolicy: Never`, and a restart
+policy rule that tells Kubernetes to restart the container in-place if it exits
+with code 42.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: restart-on-exit-codes
+  annotations:
+    kubernetes.io/description: "This Pod only restart the container only when it exits with code 42."
+spec:
+  restartPolicy: Never
+  containers:
+  - name: restart-on-exit-codes
+    image: docker.io/library/busybox:1.28
+    command: ['sh', '-c', 'sleep 60 && exit 0']
+    restartPolicy: Never     # Container restart policy must be specified if rules are specified
+    restartPolicyRules:      # Only restart the container if it exits with code 42
+    - action: Restart
+      exitCodes:
+        operator: In
+        values: [42]
+```
+
+### Example 2: A try-once init container
+
+In this example, a Pod should always be restarted once the initialization succeeds.
+However, the initialization should only be tried once.
+
+To achieve this, the Pod has an `Always` restart policy. The `init-once`
+init container will only try once. If it fails, the Pod will fail. This allows
+the Pod to fail if the initialization failed, but also keep running once the
+initialization succeeds.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: fail-pod-if-init-fails
+  annotations:
+    kubernetes.io/description: "This Pod has an init container that runs only once. After initialization succeeds, the main container will always be restarted."
+spec:
+  restartPolicy: Always
+  initContainers:
+  - name: init-once      # This init container will only try once. If it fails, the Pod will fail.
+    image: docker.io/library/busybox:1.28
+    command: ['sh', '-c', 'echo "Failing initialization" && sleep 10 && exit 1']
+    restartPolicy: Never
+  containers:
+  - name: main-container # This container will always be restarted once initialization succeeds.
+    image: docker.io/library/busybox:1.28
+    command: ['sh', '-c', 'sleep 1800 && exit 0']
+```
+
+### Example 3: Containers with different restart policies
+
+In this example, there are two containers with different restart requirements. One
+should always be restarted, while the other should only be restarted on failure.
+
+This is achieved by using a different container-level `restartPolicy` on each of
+the two containers.
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: on-failure-pod
+  annotations:
+    kubernetes.io/description: "This Pod has two containers with different restart policies."
+spec:
+  containers:
+  - name: restart-on-failure
+    image: docker.io/library/busybox:1.28
+    command: ['sh', '-c', 'echo "Not restarting after success" && sleep 10 && exit 0']
+    restartPolicy: OnFailure
+  - name: restart-always
+    image: docker.io/library/busybox:1.28
+    command: ['sh', '-c', 'echo "Always restarting" && sleep 1800 && exit 0']
+    restartPolicy: Always
+```
+
+## Learn more
+
+- Read the documentation for
+  [container restart policy](/docs/concepts/workloads/pod-lifecycle/#container-restart-rules).
+- Read the KEP for the
+  [Container Restart Rules](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5307-container-restart-policy)
+
+## Roadmap
+
+More actions and signals to restart Pods and containers are coming! Notably,
+there are plans to add support for restarting the entire Pod. Planning and
+discussions on these features are in progress. Feel free to share feedback or
+requests with the SIG Node community!
+
+## Your feedback is welcome!
+
+This is an alpha feature, and the Kubernetes project would love to hear your feedback.
+Please try it out. This feature is driven by the
+[SIG Node](https://github.com/Kubernetes/community/blob/master/sig-node/README.md).
+If you are interested in helping develop this feature, sharing feedback, or
+participating in any other ongoing SIG Node projects, please reach out to the
+SIG Node community!
+
+You can reach SIG Node by several means:
+- Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node)
+- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node)
+- [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/sig%2Fnode)