Merge branch 'kubernetes:main' into configurable-tolerance-blog

Author: jm-franc

OWNERS_ALIASES

@@ -127,6 +127,7 @@ aliases:
     - inductor
     - nasa9084
     - Okabe-Junya
+    - t-inu
   sig-docs-ja-reviews: # PR reviews for Japanese content
     - atoato88
     - b1gb4by
@@ -139,6 +140,7 @@ aliases:
   sig-docs-ko-owners: # Admins for Korean content
     - gochist
     - jihoon-seo
+    - jongwooo
     - seokho-son
     - yoonian
     - ysyukr

content/en/_index.html

@@ -6,8 +6,6 @@
   priority: 1.0
 ---
 
-{{< site-searchbar >}}
-
 {{< blocks/section class="k8s-overview" >}}
 {{% blocks/feature image="flower" id="feature-primary" %}}
 [Kubernetes]({{< relref "/docs/concepts/overview/" >}}), also known as K8s, is an open source system for automating deployment, scaling, and management of containerized applications.

content/en/blog/_posts/2025-03-12-sig-apps-spotlight.md

@@ -0,0 +1,157 @@
+---
+layout: blog
+title: "Spotlight on SIG Apps"
+slug: sig-apps-spotlight-2025
+canonicalUrl: https://www.kubernetes.dev/blog/2025/03/12/sig-apps-spotlight-2025
+date: 2025-03-12
+author: "Sandipan Panda (DevZero)"
+---
+
+In our ongoing SIG Spotlight series, we dive into the heart of the Kubernetes project by talking to
+the leaders of its various Special Interest Groups (SIGs). This time, we focus on 
+**[SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps#apps-special-interest-group)**,
+the group responsible for everything related to developing, deploying, and operating applications on
+Kubernetes. [Sandipan Panda](https://www.linkedin.com/in/sandipanpanda)
+([DevZero](https://www.devzero.io/)) had the opportunity to interview [Maciej
+Szulik](https://github.com/soltysh) ([Defense Unicorns](https://defenseunicorns.com/)) and [Janet
+Kuo](https://github.com/janetkuo) ([Google](https://about.google/)), the chairs and tech leads of
+SIG Apps. They shared their experiences, challenges, and visions for the future of application
+management within the Kubernetes ecosystem.
+
+## Introductions
+
+**Sandipan: Hello, could you start by telling us a bit about yourself, your role, and your journey
+within the Kubernetes community that led to your current roles in SIG Apps?**
+
+**Maciej**: Hey, my name is Maciej, and I’m one of the leads for SIG Apps. Aside from this role, you
+can also find me helping
+[SIG CLI](https://github.com/kubernetes/community/tree/master/sig-cli#readme) and also being one of
+the Steering Committee members. I’ve been contributing to Kubernetes since late 2014 in various
+areas, including controllers, apiserver, and kubectl.
+
+**Janet**: Certainly! I'm Janet, a Staff Software Engineer at Google, and I've been deeply involved
+with the Kubernetes project since its early days, even before the 1.0 launch in 2015.  It's been an
+amazing journey!
+
+My current role within the Kubernetes community is one of the chairs and tech leads of SIG Apps. My
+journey with SIG Apps started organically. I started with building the Deployment API and adding
+rolling update functionalities. I naturally gravitated towards SIG Apps and became increasingly
+involved. Over time, I took on more responsibilities, culminating in my current leadership roles.
+
+## About SIG Apps
+
+*All following answers were jointly provided by Maciej and Janet.*
+
+**Sandipan: For those unfamiliar, could you provide an overview of SIG Apps' mission and objectives?
+What key problems does it aim to solve within the Kubernetes ecosystem?**
+
+As described in our
+[charter](https://github.com/kubernetes/community/blob/master/sig-apps/charter.md#scope), we cover a
+broad area related to developing, deploying, and operating applications on Kubernetes. That, in
+short, means we’re open to each and everyone showing up at our bi-weekly meetings and discussing the
+ups and downs of writing and deploying various applications on Kubernetes.
+
+**Sandipan: What are some of the most significant projects or initiatives currently being undertaken
+by SIG Apps?**
+
+At this point in time, the main factors driving the development of our controllers are the
+challenges coming from running various AI-related workloads. It’s worth giving credit here to two
+working groups we’ve sponsored over the past years:
+
+1. [The Batch Working Group](https://github.com/kubernetes/community/tree/master/wg-batch), which is
+   looking at running HPC, AI/ML, and data analytics jobs on top of Kubernetes.
+2. [The Serving Working Group](https://github.com/kubernetes/community/tree/master/wg-serving), which
+   is focusing on hardware-accelerated AI/ML inference.
+
+## Best practices and challenges
+
+**Sandipan: SIG Apps plays a crucial role in developing application management best practices for
+Kubernetes. Can you share some of these best practices and how they help improve application
+lifecycle management?**
+
+1. Implementing [health checks and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
+ensures that your applications are healthy and ready to serve traffic, leading to improved
+reliability and uptime. The above, combined with comprehensive logging, monitoring, and tracing
+solutions, will provide insights into your application's behavior, enabling you to identify and
+resolve issues quickly.
+
+2. [Auto-scale your application](/docs/concepts/workloads/autoscaling/) based
+   on resource utilization or custom metrics, optimizing resource usage and ensuring your
+   application can handle varying loads.
+
+3. Use Deployment for stateless applications, StatefulSet for stateful applications, Job
+   and CronJob for batch workloads, and DaemonSet for running a daemon on each node. Use
+   Operators and CRDs to extend the Kubernetes API to automate the deployment, management, and
+   lifecycle of complex applications, making them easier to operate and reducing manual
+   intervention.
+
+**Sandipan: What are some of the common challenges SIG Apps faces, and how do you address them?**
+
+The biggest challenge we’re facing all the time is the need to reject a lot of features, ideas, and
+improvements. This requires a lot of discipline and patience to be able to explain the reasons
+behind those decisions.
+
+**Sandipan: How has the evolution of Kubernetes influenced the work of SIG Apps? Are there any
+recent changes or upcoming features in Kubernetes that you find particularly relevant or beneficial
+for SIG Apps?**
+
+The main benefit for both us and the whole community around SIG Apps is the ability to extend
+kubernetes with [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+and the fact that users can build their own custom controllers leveraging the built-in ones to
+achieve whatever sophisticated use cases they might have and we, as the core maintainers, haven’t
+considered or weren’t able to efficiently resolve inside Kubernetes.
+
+## Contributing to SIG Apps
+
+**Sandipan: What opportunities are available for new contributors who want to get involved with SIG
+Apps, and what advice would you give them?**
+
+We get the question, "What good first issue might you recommend we start with?" a lot :-) But
+unfortunately, there’s no easy answer to it. We always tell everyone that the best option to start
+contributing to core controllers is to find one you are willing to spend some time with. Read
+through the code, then try running unit tests and integration tests focusing on that
+controller. Once you grasp the general idea, try breaking it and the tests again to verify your
+breakage. Once you start feeling confident you understand that particular controller, you may want
+to search through open issues affecting that controller and either provide suggestions, explaining
+the problem users have, or maybe attempt your first fix.
+
+Like we said, there are no shortcuts on that road; you need to spend the time with the codebase to
+understand all the edge cases we’ve slowly built up to get to the point where we are. Once you’re
+successful with one controller, you’ll need to repeat that same process with others all over again.
+
+**Sandipan: How does SIG Apps gather feedback from the community, and how is this feedback
+integrated into your work?**
+
+We always encourage everyone to show up and present their problems and solutions during our
+bi-weekly [meetings](https://github.com/kubernetes/community/tree/master/sig-apps#meetings). As long
+as you’re solving an interesting problem on top of Kubernetes and you can provide valuable feedback
+about any of the core controllers, we’re always happy to hear from everyone.
+
+## Looking ahead
+
+**Sandipan: Looking ahead, what are the key focus areas or upcoming trends in application management
+within Kubernetes that SIG Apps is excited about? How is the SIG adapting to these trends?**
+
+Definitely the current AI hype is the major driving factor; as mentioned above, we have two working
+groups, each covering a different aspect of it.
+
+**Sandipan: What are some of your favorite things about this SIG?**
+
+Without a doubt, the people that participate in our meetings and on
+[Slack](https://kubernetes.slack.com/messages/sig-apps), who tirelessly help triage issues, pull
+requests and invest a lot of their time (very frequently their private time) into making kubernetes
+great!
+
+---
+
+SIG Apps is an essential part of the Kubernetes community, helping to shape how applications are
+deployed and managed at scale. From its work on improving Kubernetes' workload APIs to driving
+innovation in AI/ML application management, SIG Apps is continually adapting to meet the needs of
+modern application developers and operators. Whether you’re a new contributor or an experienced
+developer, there’s always an opportunity to get involved and make an impact.
+
+If you’re interested in learning more or contributing to SIG Apps, be sure to check out their [SIG
+README](https://github.com/kubernetes/community/tree/master/sig-apps) and join their bi-weekly [meetings](https://github.com/kubernetes/community/tree/master/sig-apps#meetings).
+
+- [SIG Apps Mailing List](https://groups.google.com/a/kubernetes.io/g/sig-apps)
+- [SIG Apps on Slack](https://kubernetes.slack.com/messages/sig-apps)

content/en/blog/_posts/2025-02-03-introducing-jobset/index.md renamed to content/en/blog/_posts/2025-03-23-introducing-jobset/index.md

@@ -1,9 +1,8 @@
 ---
 layout: blog
 title: "Introducing JobSet"
-date: 2025-02-03
+date: 2025-03-23
 slug: introducing-jobset
-draft: true
 ---
 
 **Authors**: Daniel Vega-Myhre (Google), Abdullah Gharaibeh (Google), Kevin Hannon (Red Hat)

content/en/blog/_posts/2025-02-03-introducing-jobset/jobset_diagram.svg renamed to content/en/blog/_posts/2025-03-23-introducing-jobset/jobset_diagram.svg

@@ -1,8 +1,7 @@
 ---
 layout: blog
-title: "Kubernetes 1.32: Fresh Swap Features for Linux Users"
-date: 2025-01-15T10:00:00-08:00
-draft: true
+title: "Fresh Swap Features for Linux Users in Kubernetes 1.32"
+date: 2025-03-24T10:00:00-08:00
 slug: swap-linux-improvements
 author: >
   Itamar Holder (Red Hat)

content/en/blog/_posts/2025-01-15-swap-fresh-improvements.md renamed to content/en/blog/_posts/2025-03-24-swap-fresh-improvements.md

@@ -51,7 +51,7 @@ an admin user.
 
 ## Network security
 
-- [ ] CNI plugins in-use supports network policies.
+- [ ] CNI plugins in use support network policies.
 - [ ] Ingress and egress network policies are applied to all workloads in the
   cluster.
 - [ ] Default network policies within each namespace, selecting all pods, denying
@@ -66,9 +66,8 @@ plugins provide the functionality to
 restrict network resources that pods may communicate with. This is most commonly done
 through [Network Policies](/docs/concepts/services-networking/network-policies/)
 which provide a namespaced resource to define rules. Default network policies
-blocking everything egress and ingress, in each namespace, selecting all the
-pods, can be useful to adopt an allow list approach, ensuring that no workloads
-is missed.
+that block all egress and ingress, in each namespace, selecting all pods, can be
+useful to adopt an allow list approach to ensure that no workloads are missed.
 
 Not all CNI plugins provide encryption in transit. If the chosen plugin lacks this
 feature, an alternative solution could be to use a service mesh to provide that
@@ -80,12 +79,12 @@ be used to communicate securely with it. The certificate authority for this
 should be unique to etcd.
 
 External Internet access to the Kubernetes API server should be restricted to
-not expose the API publicly. Be careful as many managed Kubernetes distribution
+not expose the API publicly. Be careful, as many managed Kubernetes distributions
 are publicly exposing the API server by default. You can then use a bastion host
 to access the server.
 
 The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) API access
-should be restricted and not publicly exposed, the defaults authentication and
+should be restricted and not exposed publicly, the default authentication and
 authorization settings, when no configuration file specified with the `--config`
 flag, are overly permissive.
 
@@ -325,7 +324,7 @@ Production.
   webhook admission controller.
 - [ ] The admission chain plugins and webhooks are securely configured.
 
-Admission controllers can help to improve the security of the cluster. However,
+Admission controllers can help improve the security of the cluster. However,
 they can present risks themselves as they extend the API server and
 [should be properly secured](/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/).
 
@@ -350,11 +349,11 @@ permission to sign certificate requests.
 attribute') of `system:masters`.
 
 [`LimitRanger`](/docs/reference/access-authn-authz/admission-controllers/#limitranger)
-: Enforce the LimitRange API constraints.
+: Enforces the LimitRange API constraints.
 
 [`MutatingAdmissionWebhook`](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)
 : Allows the use of custom controllers through webhooks, these controllers may
-mutate requests that it reviews.
+mutate requests that they review.
 
 [`PodSecurity`](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
 : Replacement for Pod Security Policy, restricts security contexts of deployed
@@ -367,8 +366,8 @@ Pods.
 : Allows the use of custom controllers through webhooks, these controllers do
 not mutate requests that it reviews.
 
-The second group includes plugin that are not enabled by default but in general
-availability state and recommended to improve your security posture:
+The second group includes plugins that are not enabled by default but are in general
+availability state and are recommended to improve your security posture:
 
 [`DenyServiceExternalIPs`](/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips)
 : Rejects all net-new usage of the `Service.spec.externalIPs` field. This is a mitigation for

content/en/docs/concepts/security/security-checklist.md

@@ -14,7 +14,7 @@ weight: 10
 
 <!-- overview -->
 
-Kubernetes _volumes_ provide a way for containers in a {{< glossary_tooltip text="pods" term_id="pod" >}}
+Kubernetes _volumes_ provide a way for containers in a {{< glossary_tooltip text="pod" term_id="pod" >}}
 to access and share data via the filesystem. There are different kinds of volume that you can use for different purposes,
 such as:
 

content/en/docs/concepts/storage/volumes.md

@@ -33,9 +33,7 @@ presents a valid certificate signed by the cluster's certificate authority
 the username from the common name field in the 'subject' of the cert (e.g.,
 "/CN=bob"). From there, the role based access control (RBAC) sub-system would
 determine whether the user is authorized to perform a specific operation on a
-resource. For more details, refer to the normal users topic in
-[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
-for more details about this.
+resource.
 
 In contrast, service accounts are users managed by the Kubernetes API. They are
 bound to specific namespaces, and created automatically by the API server or
@@ -1815,5 +1813,6 @@ You can only make `SelfSubjectReview` requests if:
 
 ## {{% heading "whatsnext" %}}
 
+* To learn about issuing certificates for users, read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
 * Read the [client authentication reference (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
 * Read the [client authentication reference (v1)](/docs/reference/config-api/client-authentication.v1/)