Merge pull request #48640 from hacktivist123/merged-main-dev-1.32

Merged main dev 1.32

Author: k8s-ci-robot

content/bn/community/static/cncf-code-of-conduct.md

@@ -81,5 +81,5 @@ CNCF সনদের সাথে সামঞ্জস্যপূর্ণ, 
 ## স্বীকারোক্তি (Acknowledgements)
 
 এই আচরণবিধিটি অবদানকারী চুক্তি থেকে অভিযোজিত
-(http://contributor-covenant.org), সংস্করণ 2.0 এখানে উপলব্ধ
-http://contributor-covenant.org/version/2/0/code_of_conduct/
+(https://contributor-covenant.org), সংস্করণ 2.0 এখানে উপলব্ধ
+https://contributor-covenant.org/version/2/0/code_of_conduct/

content/en/blog/_posts/2024-10-28-k8s-upstream-training-japan-spotlight/index.md

@@ -5,12 +5,10 @@ slug: k8s-upstream-training-japan-spotlight
 date: 2024-10-28
 canonicalUrl: https://www.k8s.dev/blog/2024/10/28/k8s-upstream-training-japan-spotlight/
 author: >
-  [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba)
+  [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba) / 
   Organizing team of Kubernetes Upstream Training in Japan
 ---
 
-## About our team
-
 We are organizers of [Kubernetes Upstream Training in Japan](https://github.com/kubernetes-sigs/contributor-playground/tree/master/japan).
 Our team is composed of members who actively contribute to Kubernetes, including individuals who hold roles such as member, reviewer, approver, and chair.
 

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -39,7 +39,7 @@ assigning a Pod to a specific node is called _binding_, and the process of selec
 which node to use is called _scheduling_.
 Once a Pod has been scheduled and is bound to a node, Kubernetes tries
 to run that Pod on the node. The Pod runs on that node until it stops, or until the Pod
-is [terminated](#pod-termination); if Kubernetes isn't able start the Pod on the selected
+is [terminated](#pod-termination); if Kubernetes isn't able to start the Pod on the selected
 node (for example, if the node crashes before the Pod starts), then that particular Pod
 never starts.
 

content/en/docs/concepts/workloads/pods/sidecar-containers.md

@@ -97,6 +97,12 @@ maintain sidecar containers without affecting the primary application.
 Sidecar containers share the same network and storage namespaces with the primary
 container. This co-location allows them to interact closely and share resources.
 
+From Kubernetes perspective, sidecars graceful termination is less important. 
+When other containers took all alloted graceful termination time, sidecar containers
+will receive the `SIGTERM` following with `SIGKILL` faster than may be expected. 
+So exit codes different from `0` (`0` indicates successful exit), for sidecar containers are normal
+on Pod termination and should be generally ignored by the external tooling.
+
 ## Differences from init containers
 
 Sidecar containers work alongside the main container, extending its functionality and

content/en/docs/contribute/participate/_index.md

@@ -93,7 +93,7 @@ and editorial review of their PR.
 
 ## How merging works
 
-When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that
+When a pull request is merged to the branch used to publish content, that content is published to https://kubernetes.io. To ensure that
 the quality of our published content is high, we limit merging pull requests to
 SIG Docs approvers. Here's how it works.
 

content/en/docs/contribute/review/reviewing-prs.md

@@ -163,6 +163,48 @@ When reviewing, use the following as a starting point.
 - Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code
   blocks, tables, notes and images.
 
+### Blog
+
+- Early feedback on blog posts is welcome via a Google Doc or HackMD. Please request input early from the [#sig-docs-blog Slack channel](https://kubernetes.slack.com/archives/CJDHVD54J).
+- Before reviewing blog PRs, be familiar with [Submitting blog posts and case studies](/docs/contribute/new-content/blogs-case-studies/).
+- We are willing to mirror any blog article that was published to https://kubernetes.dev/blog/ (the contributor blog) provided that:
+- the mirrored article has the same publication date as the original (it should have the same publication time too, but you can also set a time stamp up to 12 hours later for special cases)
+  - for PRs that arrive the original article was merged to https://kubernetes.dev/, there haven't been 
+  (and won't be) any articles published to the main blog between time that the original and mirrored article 
+  [will] publish. 
+  This is because we don't want to add articles to people's feeds, such as RSS, except at the very end of their feed.
+  - the original article doesn't contravene any strongly recommended review guidelines or community norms.
+  - You should set the canonical URL for the mirrored article, to the URL of the original article 
+  (you can use a preview to predict the URL and fill this in ahead of actual publication). Use the `canonicalUrl` 
+  field in [front matter](https://gohugo.io/content-management/front-matter/) for this.
+- Consider the target audience and whether the blog post is appropriate for kubernetes.io 
+  For example, if the target audience are Kubernetes contributors only then kubernetes.dev
+  may be more appropriate, 
+  or if the blog post is on general platform engineering then it may be more suitable on another site.
+
+  This consideration applies to mirrored articles too; although we are willing to consider all valid
+  contributor articles for mirroring if a PR is opened, we don't mirror all of them.
+
+- We only mark blog articles as maintained (`evergreen: true` in front matter) if the Kubernetes project 
+  is happy to commit to maintaining them indefinitely. Some blog articles absolutely merit this, and we 
+  always mark our release announcements evergreen. Check with other contributors if you are not sure 
+  how to review on this point.
+- The [content guide](/docs/contribute/style/content-guide/) applies unconditionally to blog articles
+  and the PRs that add them. Bear in mind that some restrictions in the guide state that they are only relevant to documentation; those restrictions don't apply to blog articles.
+- The [style guide](/docs/contribute/style/style-guide/) largely also applies to blog PRs, but we make some exceptions.
+  
+  - it is OK to use “we“ in a blog article that has multiple authors, or where the article introduction clearly indicates that the author is writing on behalf of a specific group.
+  - we avoid using Kubernetes shortcodes for callouts (such as `{{</* caution */>}}`)
+  - statements about the future are OK, albeit we use them with care in official announcements on
+    behalf of Kubernetes
+  - code samples don't need to use the `{{</* code_sample */>}}` shortcode, and often it is better if they do not
+  - we are OK to have authors write an article in their own writing style, so long as most readers
+    would follow the point being made
+- The [diagram guide](/docs/contribute/style/diagram-guide/) is aimed at Kubernetes documentation,
+  not blog articles. It is still good to align with it but:
+  - we prefer SVG over raster diagram formats, and also over Mermaid (you can still capture the Mermaid source in a comment)
+  - there is no need to caption diagrams as Figure 1, Figure 2 etc
+
 ### Other
 
 - Watch out for [trivial edits](https://www.kubernetes.dev/docs/guide/pull-requests/#trivial-edits);
@@ -181,5 +223,4 @@ This lets the author know that this part of your feedback is non-critical.
 If you are considering a pull request for approval and all the remaining feedback is
 marked as a nit, you can merge the PR anyway. In that case, it's often useful to open
 an issue about the remaining nits. Consider whether you're able to meet the requirements
-for marking that new issue as a [Good First Issue](https://www.kubernetes.dev/docs/guide/help-wanted/#good-first-issue);
-if you can, these are a good source.
+for marking that new issue as a [Good First Issue](https://www.kubernetes.dev/docs/guide/help-wanted/#good-first-issue); if you can, these are a good source.

content/en/docs/reference/command-line-tools-reference/feature-gates/recursive-read-only-mounts.md

@@ -9,6 +9,10 @@ stages:
   - stage: alpha
     defaultValue: false
     fromVersion: "1.30"
+    toVersion: "1.30"
+  - stage: beta
+    defaultValue: true
+    fromVersion: "1.31"
 ---
 Enables support for recursive read-only mounts.
 For more details, see [read-only mounts](/docs/concepts/storage/volumes/#read-only-mounts).

content/en/docs/reference/glossary/pod-disruption-budget.md

@@ -4,7 +4,7 @@ title: Pod Disruption Budget
 full-link: /docs/concepts/workloads/pods/disruptions/
 date: 2019-02-12
 short_description: >
- An object that limits the number of {{< glossary_tooltip text="Pods" term_id="pod" >}} of a replicated application, that are down simultaneously from voluntary disruptions.
+ An object that limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions.
 
 aka:
  - PDB
@@ -17,8 +17,8 @@ tags:
 
  A [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) allows an 
  application owner to create an object for a replicated application, that ensures 
- a certain number or percentage of Pods with an assigned label will not be voluntarily
- evicted at any point in time.
+ a certain number or percentage of {{< glossary_tooltip text="Pods" term_id="pod" >}}
+ with an assigned label will not be voluntarily evicted at any point in time.
 
 <!--more-->