Merge main branch into dev-1.33

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-01-15-swap-fresh-improvements.md → content/en/blog/_posts/2025-03-24-swap-fresh-improvements.md

@@ -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/docs/reference/access-authn-authz/authentication.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/)

content/en/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -489,133 +489,10 @@ signer-unlinked ClusterTrustBundles **must not** contain a colon (`:`).
 The contents of ClusterTrustBundles can be injected into the container filesystem, similar to ConfigMaps and Secrets.
 See the [clusterTrustBundle projected volume source](/docs/concepts/storage/projected-volumes#clustertrustbundle) for more details.
 
-<!-- TODO this should become a task page -->
-## How to issue a certificate for a user {#normal-user}
-
-A few steps are required in order to get a normal user to be able to
-authenticate and invoke an API. First, this user must have a certificate issued
-by the Kubernetes cluster, and then present that certificate to the Kubernetes API.
-
-### Create private key
-
-The following scripts show how to generate PKI private key and CSR. It is
-important to set CN and O attribute of the CSR. CN is the name of the user and
-O is the group that this user will belong to. You can refer to
-[RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
-
-```shell
-openssl genrsa -out myuser.key 2048
-openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"
-```
-
-### Create a CertificateSigningRequest {#create-certificatessigningrequest}
-
-Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
-and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the
-CertificateSigningRequest.
-
-```shell
-cat <<EOF | kubectl apply -f -
-apiVersion: certificates.k8s.io/v1
-kind: CertificateSigningRequest
-metadata:
-  name: myuser
-spec:
-  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
-  signerName: kubernetes.io/kube-apiserver-client
-  expirationSeconds: 86400  # one day
-  usages:
-  - client auth
-EOF
-```
-
-Some points to note:
-
-- `usages` has to be '`client auth`'
-- `expirationSeconds` could be made longer (i.e. `864000` for ten days) or shorter (i.e. `3600` for one hour)
-- `request` is the base64 encoded value of the CSR file content.
-  You can get the content using this command: 
-
-  ```shell
-  cat myuser.csr | base64 | tr -d "\n"
-  ```
-
-
-### Approve the CertificateSigningRequest {#approve-certificate-signing-request}
-
-Use kubectl to create a CSR and approve it.
-
-Get the list of CSRs:
-
-```shell
-kubectl get csr
-```
-
-Approve the CSR:
-
-```shell
-kubectl certificate approve myuser
-```
-
-### Get the certificate
-
-Retrieve the certificate from the CSR:
-
-```shell
-kubectl get csr/myuser -o yaml
-```
-
-The certificate value is in Base64-encoded format under `status.certificate`.
-
-Export the issued certificate from the CertificateSigningRequest.
-
-```shell
-kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
-```
-
-### Create Role and RoleBinding
-
-With the certificate created it is time to define the Role and RoleBinding for
-this user to access Kubernetes cluster resources.
-
-This is a sample command to create a Role for this new user:
-
-```shell
-kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
-```
-
-This is a sample command to create a RoleBinding for this new user:
-
-```shell
-kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
-```
-
-### Add to kubeconfig
-
-The last step is to add this user into the kubeconfig file.
-
-First, you need to add new credentials:
-
-```shell
-kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
-
-```
-
-Then, you need to add the context:
-
-```shell
-kubectl config set-context myuser --cluster=kubernetes --user=myuser
-```
-
-To test it, change the context to `myuser`:
-
-```shell
-kubectl config use-context myuser
-```
-
 ## {{% heading "whatsnext" %}}
 
 * Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
+* Read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
 * View the source code for the kube-controller-manager built in
   [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
 * View the source code for the kube-controller-manager built in

content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md

@@ -146,7 +146,7 @@ option. Your cluster requirements may need a different configuration.
    connection:
 
    ```shell
-   nc -v <LOAD_BALANCER_IP> <PORT>
+   nc -zv -w 2 <LOAD_BALANCER_IP> <PORT>
    ```
 
    A connection refused error is expected because the API server is not yet

content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md

@@ -60,7 +60,7 @@ need to be open in order for Kubernetes components to communicate with each othe
 You can use tools like [netcat](https://netcat.sourceforge.net) to check if a port is open. For example:
 
 ```shell
-nc 127.0.0.1 6443 -v
+nc 127.0.0.1 6443 -zv -w 2
 ```
 
 The pod network plugin you use may also require certain ports to be