Merge main into dev-1.32 to keep in sync

.github/workflows/update-schedule.yml

@@ -0,0 +1,52 @@
+name: Update schedule.yaml
+on:
+  workflow_dispatch:
+  schedule:
+    - cron: '0 0 * * *'  # daily
+jobs:
+  create-pull-request:
+    name: Create PR (if required)
+    permissions:
+      contents: write
+      pull-requests: write
+    if: github.repository == 'kubernetes/website'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repository code
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-go@0c52d547c9bc32b1aa3301fd7a9cb496313a4491 # v5.0.0
+        with:
+          go-version: '1.22'
+          check-latest: true
+
+      - name: Install schedule-builder
+        run: go install k8s.io/release/cmd/schedule-builder@v0.16.9
+
+      - name: Update schedule.yaml
+        run: schedule-builder -uc data/releases/schedule.yaml -e data/releases/eol.yaml
+
+      - name: Check workspace
+        id: create_pr
+        run: |
+          if [[ $(git diff --stat) != '' ]]; then
+            echo "create_pr=true" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Create Pull Request
+        uses: peter-evans/create-pull-request@70a41aba780001da0a30141984ae2a0c95d8704e # v6.0.2
+        if: ${{ steps.create_pr.outputs.create_pr == 'true' }}
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          commit-message: Update schedule.yaml
+          title: Update release schedule.yaml
+          body: |
+            Update release schedule.yaml
+
+            /cc @kubernetes/release-managers
+          labels: area/release-eng, sig/release, sig/docs
+          branch: update-schedule
+          delete-branch: true
+          signoff: true

Dockerfile

@@ -4,7 +4,7 @@
 # change is that the Hugo version is now an overridable argument rather than a fixed
 # environment variable.
 
-FROM docker.io/library/golang:1.20-alpine
+FROM docker.io/library/golang:1.23.0-alpine3.20
 
 LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
 
@@ -24,7 +24,7 @@ RUN mkdir $HOME/src && \
     cd "hugo-${HUGO_VERSION}" && \
     go install --tags extended
 
-FROM docker.io/library/golang:1.20-alpine
+FROM docker.io/library/golang:1.23.0-alpine3.20
 
 RUN apk add --no-cache \
     runuser \

Makefile

@@ -81,7 +81,7 @@ container-push: container-image ## Push container image for the preview of the w
 
 PLATFORMS ?= linux/arm64,linux/amd64
 docker-push: ## Build a multi-architecture image and push that into the registry
-	docker run --rm --privileged tonistiigi/binfmt:qemu-v6.2.0-26@sha256:5bf63a53ad6222538112b5ced0f1afb8509132773ea6dd3991a197464962854e --install all
+	docker run --rm --privileged tonistiigi/binfmt:qemu-v8.1.5-43@sha256:46c5a036f13b8ad845d6703d38f8cce6dd7c0a1e4d42ac80792279cabaeff7fb --install all
 	docker version
 	$(DOCKER_BUILDX) version
 	$(DOCKER_BUILDX) inspect image-builder > /dev/null 2>&1 || $(DOCKER_BUILDX) create --name image-builder --use

OWNERS_ALIASES

@@ -108,6 +108,7 @@ aliases:
     - bishal7679
     - dipesh-rawat
     - divya-mohan0209
+    - niranjandarshann
   sig-docs-id-owners: # Admins for Indonesian content
     - ariscahyadi
     - danninov

README-bn.md

@@ -186,7 +186,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 
 | Name                       | Slack                      | GitHub                     |                   
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh               | @sreeram.venkitesh                      | @sreeram-venkitesh              |
 
 ## Localization READMEs
 

README-es.md

@@ -36,7 +36,6 @@ El sitio web de Kubernetes utiliza Docsy Hugo theme. Se sugiere que se instale s
 ```bash
 # pull de los submódulos del repositorio
 git submodule update --init --recursive --depth 1
-
 ```
 
 Si identifica que `git` reconoce una cantidad innumerable de cambios nuevos en el proyecto, la forma más simple de solucionarlo es cerrando y volviendo a abrir el proyecto en el editor. Los submódulos son automáticamente detectados por `git`, pero los plugins usados por los editores pueden tener dificultades para ser cargados.

README-ja.md

@@ -64,16 +64,19 @@ make container-serve
 ローカルで依存関係をインストールし、サイトを構築してテストするには、次のコマンドを実行します。
 
 - For macOS and Linux
+
   ```bash
   npm ci
   make serve
   ```
+  
 - For Windows (PowerShell)
+
   ```powershell
   npm ci
   hugo.exe server --buildFuture --environment development
   ```
-
+  
 これで、Hugoのサーバーが1313番ポートを使って起動します。使用しているブラウザで<http://localhost:1313>にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
 
 ## API reference pagesをビルドする
@@ -196,7 +199,7 @@ Kubernetesのドキュメントへの貢献に関する詳細については以
 
 | 名前                       | Slack                      | GitHub                     |                   
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh                | @sreeram.venkitesh                      | @sreeram-venkitesh              |
 
 ## 翻訳された`README.md`一覧 {#localization-readmemds}
 

README-ko.md

@@ -173,7 +173,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 
 | Name                       | Slack                      | GitHub                     |                   
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh               | @sreeram.venkitesh                      | @sreeram-venkitesh              |
 
 # `README.md`에 대한 쿠버네티스 문서 현지화(localization) {#localization-readmemds}
 

README-pt.md

@@ -187,7 +187,7 @@ Caso você precise de ajuda em algum momento ao contribuir, os [Embaixadores par
 
 | Nome                       | Slack                      | GitHub                     |                   
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh                | @sreeram.venkitesh                      | @sreeram-venkitesh              |
 
 ## Traduções do `README.md`
 

README-uk.md

@@ -186,7 +186,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 
 | Імʼя                       | Slack                      | GitHub                     |                   
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh                | @sreeram.venkitesh                      | @sreeram-venkitesh              |
 
 ## Локалізовані файли README
 

README-vi.md

@@ -194,7 +194,7 @@ Nếu bạn cần trợ giúp bất kỳ lúc nào khi đóng góp, [Đại sứ
 
 | Name                       | Slack                      | GitHub                     |
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh              | @sreeram.venkitesh                   | @sreeram-venkitesh              |
 
 ## Các tệp README đa ngôn ngữ
 

README-zh.md

@@ -429,13 +429,14 @@ If you need help at any point when contributing, the [New Contributor Ambassador
 SIG Docs 的当前新贡献者大使：
 
 <!--
-| Name                       | Slack                      | GitHub                     |                   
+| Name                       | Slack                      | GitHub                     |
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh          | @sreeram.venkitesh         | @sreeram-venkitesh         |
 -->
 | 姓名                       | Slack                      | GitHub                     |
 | -------------------------- | -------------------------- | -------------------------- |
-| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+| Sreeram Venkitesh          | @sreeram.venkitesh         | @sreeram-venkitesh         |
+
 
 <!--
 ## Localization READMEs

README.md

@@ -33,12 +33,14 @@ cd website
 The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
 
 ### Windows
+
 ```powershell
 # fetch submodule dependencies
 git submodule update --init --recursive --depth 1
 ```
 
 ### Linux / other Unix
+
 ```bash
 # fetch submodule dependencies
 make module-init
@@ -62,11 +64,14 @@ Open up your browser to <http://localhost:1313> to view the website. As you make
 To install dependencies, deploy and test the site locally, run:
 
 - For macOS and Linux
+
   ```bash
   npm ci
   make serve
   ```
+
 - For Windows (PowerShell)
+
   ```powershell
   npm ci
   hugo.exe server --buildFuture --environment development

api-ref-assets/config/fields.yaml

@@ -63,14 +63,16 @@
 - definition: io.k8s.api.core.v1.PodSecurityContext
   field_categories:
   - fields:
+    - appArmorProfile
+    - fsGroup
+    - fsGroupChangePolicy
     - runAsUser
     - runAsNonRoot
     - runAsGroup
-    - supplementalGroups
-    - fsGroup
-    - fsGroupChangePolicy
     - seccompProfile
     - seLinuxOptions
+    - supplementalGroups
+    - supplementalGroupsPolicy
     - sysctls
     - windowsOptions
 
@@ -166,30 +168,36 @@
 - definition: io.k8s.api.core.v1.SecurityContext
   field_categories:
   - fields:
+    - allowPrivilegeEscalation
+    - appArmorProfile
+    - capabilities
+    - procMount
+    - privileged
+    - readOnlyRootFilesystem
     - runAsUser
     - runAsNonRoot
     - runAsGroup
-    - readOnlyRootFilesystem
-    - procMount
-    - privileged
-    - allowPrivilegeEscalation
-    - capabilities
-    - seccompProfile
     - seLinuxOptions
+    - seccompProfile
     - windowsOptions
 
 - definition: io.k8s.api.core.v1.ContainerStatus
   field_categories:
   - fields:
-    - name
+    - allocatedResources
+    - allocatedResourcesStatus
+    - containerID
     - image
     - imageID
-    - containerID
-    - state
     - lastState
+    - name
     - ready
+    - resources
     - restartCount
     - started
+    - state
+    - user
+    - volumeMounts
 
 - definition: io.k8s.api.core.v1.ContainerStateTerminated
   field_categories:
@@ -400,9 +408,11 @@
   - name: Beta level
     fields:
     - podFailurePolicy
+    - successPolicy
   - name: Alpha level
     fields:
     - backoffLimitPerIndex
+    - managedBy
     - maxFailedIndexes
     - podReplacementPolicy
 
@@ -491,6 +501,7 @@
     - publishNotReadyAddresses
     - sessionAffinityConfig
     - allocateLoadBalancerNodePorts
+    - trafficDistribution
 
 - definition: io.k8s.api.core.v1.ServicePort
   field_categories:
@@ -557,6 +568,7 @@
     - gcePersistentDisk
     - glusterfs
     - iscsi
+    - image
     - nfs
     - photonPersistentDisk
     - portworxVolume
@@ -618,6 +630,7 @@
     fields:
     - dataSource
     - dataSourceRef
+    - volumeAttributesClassName
 
 - definition: io.k8s.api.core.v1.PersistentVolumeSpec
   field_categories:
@@ -629,6 +642,7 @@
     - nodeAffinity
     - persistentVolumeReclaimPolicy
     - storageClassName
+    - volumeAttributesClassName
     - volumeMode
   - name: Local
     fields:
@@ -666,6 +680,11 @@
     - resourceNames
     - nonResourceURLs
 
+- definition: io.k8s.api.networking.v1beta1.IPAddressSpec
+  field_categories:
+  - fields:
+    - parentRef
+
 - definition: io.k8s.api.networking.v1.NetworkPolicySpec
   field_categories:
   - fields:
@@ -687,6 +706,11 @@
     - endPort
     - protocol
 
+- definition: io.k8s.api.networking.v1beta1.ServiceCIDRSpec
+  field_categories:
+  - fields:
+    - cidrs
+
 - definition: io.k8s.api.policy.v1beta1.PodSecurityPolicySpec
   field_categories:
   - fields:
@@ -737,3 +761,38 @@
     - resourceVersion
     - selfLink
     - uid
+
+- definition: io.k8s.api.storagemigration.v1alpha1.StorageVersionMigrationSpec
+  field_categories:
+  - fields:
+    - continueToken
+    - resource
+
+- definition: io.k8s.api.storagemigration.v1alpha1.StorageVersionMigrationSpec
+  field_categories:
+  - fields:
+    - driverName
+    - parameters
+
+- definition: io.k8s.api.resource.v1alpha3.DeviceClassSpec
+  field_categories:
+  - fields:
+    - config
+    - selectors
+    - suitableNodes
+
+- definition: io.k8s.api.flowcontrol.v1.FlowSchemaSpec
+  field_categories:
+  - fields:
+    - distinguisherMethod
+    - matchingPrecedence
+    - priorityLevelConfiguration
+    - rules
+
+- definition: io.k8s.api.flowcontrol.v1.PriorityLevelConfigurationSpec
+  field_categories:
+  - fields:
+    - exempt
+    - limited
+    - type
+

api-ref-assets/config/toc.yaml

@@ -30,6 +30,9 @@ parts:
     - Probe
     - PodStatus
     - PodList
+  - name: Binding
+    group: ""
+    version: v1
   - name: PodTemplate
     group: ""
     version: v1
@@ -68,16 +71,16 @@ parts:
     version: v1
   - name: PodSchedulingContext
     group: resource.k8s.io
-    version: v1alpha2
+    version: v1alpha3
   - name: ResourceClaim
     group: resource.k8s.io
-    version: v1alpha2
+    version: v1alpha3
   - name: ResourceClaimTemplate
     group: resource.k8s.io
-    version: v1alpha2
+    version: v1alpha3
-  - name: ResourceClass
+  - name: ResourceSlice
     group: resource.k8s.io
-    version: v1alpha2
+    version: v1alpha3
 - name: Service Resources
   chapters:
   - name: Service
@@ -108,23 +111,6 @@ parts:
   - name: Secret
     group: ""
     version: v1
-  - name: Volume
-    key: io.k8s.api.core.v1.Volume
-    otherDefinitions:
-    - DownwardAPIVolumeFile
-    - KeyToPath
-  - name: PersistentVolumeClaim
-    group: ""
-    version: v1
-  - name: PersistentVolume
-    group: ""
-    version: v1
-  - name: StorageClass
-    group: storage.k8s.io
-    version: v1
-  - name: VolumeAttachment
-    group: storage.k8s.io
-    version: v1
   - name: CSIDriver
     group: storage.k8s.io
     version: v1
@@ -134,6 +120,29 @@ parts:
   - name: CSIStorageCapacity
     group: storage.k8s.io
     version: v1
+  - name: PersistentVolumeClaim
+    group: ""
+    version: v1
+  - name: PersistentVolume
+    group: ""
+    version: v1
+  - name: StorageClass
+    group: storage.k8s.io
+    version: v1
+  - name: StorageVersionMigration
+    group: storagemigration.k8s.io
+    version: v1alpha1
+  - name: Volume
+    key: io.k8s.api.core.v1.Volume
+    otherDefinitions:
+    - DownwardAPIVolumeFile
+    - KeyToPath
+  - name: VolumeAttachment
+    group: storage.k8s.io
+    version: v1
+  - name: VolumeAttributesClass
+    group: storage.k8s.io
+    version: v1beta1
 - name: Authentication Resources
   chapters:
   - name: ServiceAccount
@@ -182,6 +191,9 @@ parts:
     version: v1
 - name: Policy Resources
   chapters:
+  - name: FlowSchema
+    group: flowcontrol.apiserver.k8s.io
+    version: v1
   - name: LimitRange
     group: ""
     version: v1
@@ -194,9 +206,21 @@ parts:
   - name: PodDisruptionBudget
     group: policy
     version: v1
-  - name: IPAddress
+  - name: PriorityLevelConfiguration
-    group: networking.k8s.io
+    group: flowcontrol.apiserver.k8s.io
-    version: v1alpha1
+    version: v1
+  - name: ValidatingAdmissionPolicy
+    group: admissionregistration.k8s.io
+    version: v1
+    otherDefinitions:
+    - ValidatingAdmissionPolicyList
+    - ValidatingAdmissionPolicyBinding
+  - name: ValidatingAdmissionPolicyBinding
+    group: admissionregistration.k8s.io
+    version: v1
+    otherDefinitions:
+    - ValidatingAdmissionPolicy
+    - ValidatingAdmissionPolicyBindingList
 - name: Extend Resources
   chapters:
   - name: CustomResourceDefinition
@@ -207,53 +231,49 @@ parts:
     - JSONSchemaProps
     - CustomResourceDefinitionStatus
     - CustomResourceDefinitionList
+  - name: DeviceClass
+    group: resource.k8s.io
+    version: v1alpha3
   - name: MutatingWebhookConfiguration
     group: admissionregistration.k8s.io
     version: v1
   - name: ValidatingWebhookConfiguration
     group: admissionregistration.k8s.io
     version: v1
-  - name: ValidatingAdmissionPolicy
-    group: admissionregistration.k8s.io
-    version: v1beta1
     otherDefinitions:
-    - ValidatingAdmissionPolicyList
+    - ValidatingWebhookConfigurationList
-    - ValidatingAdmissionPolicyBinding
 - name: Cluster Resources
   chapters:
-  - name: Node
+  - name: APIService
-    group: ""
+    group: apiregistration.k8s.io
     version: v1
-  - name: Namespace
+  - name: ComponentStatus
     group: ""
     version: v1
   - name: Event
     group: events.k8s.io
     version: v1
-  - name: APIService
+  - name: IPAddress
-    group: apiregistration.k8s.io
+    group: networking.k8s.io
-    version: v1
+    version: v1beta1
   - name: Lease
     group: coordination.k8s.io
     version: v1
+  - name: LeaseCandidate
+    group: coordination.k8s.io
+    version: v1alpha1
+  - name: Namespace
+    group: ""
+    version: v1
+  - name: Node
+    group: ""
+    version: v1
   - name: RuntimeClass
     group: node.k8s.io
     version: v1
-  - name: FlowSchema
+  - name: ServiceCIDR
-    group: flowcontrol.apiserver.k8s.io
-    version: v1beta3
-  - name: PriorityLevelConfiguration
-    group: flowcontrol.apiserver.k8s.io
-    version: v1beta3
-  - name: Binding
-    group: ""
-    version: v1
-  - name: ComponentStatus
-    group: ""
-    version: v1
-  - name: ClusterCIDR
     group: networking.k8s.io
-    version: v1alpha1
+    version: v1beta1
 - name: Common Definitions
   chapters:
   - name: DeleteOptions

api-ref-generator

@@ -1 +1 @@
-Subproject commit 55bce686224caba37f93e1e1eb53c0c9fc104ed4
+Subproject commit 096a94d6e7d0d04e41356f21233498c3c4e31699

assets/css/glossary.css

@@ -1,60 +0,0 @@
-.preview-text p {
-  display: inline;
-}
-
-.permalink {
-  background-image: url(../images/link.png);
-  background-repeat: no-repeat;
-  display: inline-block;
-  vertical-align: middle;
-  font-size: 0;
-  color: transparent;
-  width: 17px;
-  height: 17px;
-  margin-left: 10px;
-}
-
-.term-anchor {
-  display: block;
-  position: relative;
-  top: -90px;
-  visibility: hidden;
-}
-
-.tag-option {
-  padding: 5px;
-  margin: 10px;
-  float:left;
-}
-
-.canonical-tag {
-  color: white;
-  background-color: #b7c8e8;
-}
-
-.canonical-tag a {
-  color: inherit;
-  text-decoration: none !important;
-}
-
-.active-tag {
-  background-color: #326ce5;
-}
-
-.invisible {
-  visibility: hidden;
-}
-
-#tag-container {
-  float: left;
-  width: 100%;
-  border-top: 1px solid #8c8c8c;
-  border-bottom: 1px solid #8c8c8c;
-  padding: 7px 0px;
-  margin: 25px 0px;
-}
-
-.tag-description {
-  text-align: center;
-  margin: 5px 0px;
-}

assets/js/glossary.js

@@ -149,16 +149,6 @@ $( document ).ready(function() {
         }
       });
     });
-
-    // Shows permalink when term name is hovered over
-    $(".term-name").each(function() {
-      var permalink = $($(this).parent().find(".permalink")[0]);
-      $(this).mouseenter(function(){
-        permalink.removeClass("hide");
-      }).mouseleave(function(){
-        permalink.addClass("hide");
-      });
-    });
   };
 
   function initActiveTags() {

assets/scss/_base.scss

@@ -94,7 +94,7 @@ footer {
 }
 
 main {
-  .button {
+  .button, .portal-button {
     display: inline-block;
     border-radius: 6px;
     padding: 6px 20px;

assets/scss/_custom.scss

@@ -626,6 +626,155 @@ body.td-home #deprecation-warning {
     margin-right: auto;
 }
 
+body.glossary {
+  main {
+    ul.glossary-terms > li {
+      list-style-type: none;
+      padding: 0.5em;
+      padding-bottom: calc(min(0.5em, 0.25em + 0.15vh ));
+      margin: 0;
+      margin-top: calc(min(1.0em, 0.25em + 0.15vh ));
+    }
+    ul.glossary-terms > li.hide {
+      display: none;
+    }
+    ul.glossary-terms > li:has(.term-anchor:target) {
+      border-left: 0.3em solid $blue;
+      background: rgba(#999999, 0.2);
+    }
+    #tag-container {
+      float: left;
+      max-width: calc(max(80%, 100em));
+      border-top: 1px solid #999999;
+      border-bottom: 1px solid #999999;
+      padding-top: 0.5em 0;
+      margin: 2em 0;
+      > p {
+        display: inline-block;
+        padding-top: 0.2em;
+      }
+      .hide {
+        display: none;
+      }
+      .tag-option {
+        border-radius: 0.33em;
+        padding: 0.5em;
+        padding-left: 0.6em;
+        padding-right: 0.75em;
+        margin: 0.75em;
+        margin-top: 0.1em;
+        float: left;
+        font-weight: bold;
+        font-size: 0.925em;
+      }
+      .tag-option:not(.canonical-tag):hover {
+        outline: 1.5px solid $blue;
+      }
+      .tag-description {
+        margin-left: auto;
+        margin-right: auto;
+        padding: 0.2em;
+        padding-bottom: 0.8em;
+        text-align: center;
+      }
+      .canonical-tag {
+        color: white;
+        background-color: #999999;
+      }
+      .canonical-tag a {
+        color: inherit;
+        background: transparent;
+        text-decoration: none !important;
+      }
+      .active-tag {
+        color: $white;
+        background-color: $blue;
+      }
+      // darken on hover
+      .canonical-tag:hover {
+        background: darken(#999999, 15%)
+      }
+      .canonical-tag.active-tag:hover {
+        background: darken($blue, 15%)
+      }
+    }
+    .term-anchor:target + .term-name > span {
+      color: $blue;
+    }
+    .term-anchor:target {
+      visibility: initial;
+    }
+    .glossary-term-name {
+      font-weight: bold;
+      display: inline-block;
+      padding-left: 0.25em;
+      padding-right: 0.25em;
+    }
+    .glossary-aka {
+      display: inline-block;
+      padding-left: 0.25em;
+      padding-right: 0.25em;
+      padding-bottom: 0.25em;
+    }
+    #glossary-details-before {
+       margin-top: 3em;
+       font-style: italic;
+       clear: both;
+    }
+    .preview-text {
+      display: inline-block;
+      margin-bottom: 0.2em;
+    }
+    .preview-text + * {
+      margin-top: 0.2em;
+    }
+    .term-definition {
+       margin-left: calc(min(2em, 0.5em + 0.75vw));
+       .hide {
+          display: none;
+       }
+    }
+    .glossary-aka {
+      font-style: italic;
+    }
+    .preview-text p {
+      display: inline;
+    }
+    .permalink {
+      display: inline-block;
+      background-image: url(../images/link.png);
+      background-repeat: no-repeat;
+      background-size: contain;
+      width: 1em;
+      height: 1em;
+      padding-left: 0.1em;
+    }
+    .term-name:hover {
+      color: $blue;
+    }
+    .term-name:not(:hover) > .permalink {
+      visibility: hidden;
+    }
+    .term-anchor {
+      display: block;
+      position: relative;
+      top: -4rem; // adjust scrolling to target
+      visibility: hidden;
+    }
+    .invisible {
+      visibility: hidden;
+    }
+  }
+}
+
+body.cid-community {
+  section.linkbox {
+    max-width: clamp(50%, calc(100em + 2vw), 100vw);
+    margin-left: auto;
+    margin-right: auto;
+  }
+}
+
 #caseStudies body > #deprecation-warning, body.cid-casestudies > #deprecation-warning, body.cid-community > #deprecation-warning {
     display: inline-block;
     vertical-align: top;

content/bn/blog/_posts/2024-05-09-gateway-api-v1.1/gateway-api-logo.svg

@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="900px" height="250px" style="shape-rendering:geometricPrecision; text-rendering:geometricPrecision; image-rendering:optimizeQuality; fill-rule:evenodd; clip-rule:evenodd" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g><path style="opacity:0.908" fill="#fbfcfe" d="M 134.5,17.5 C 137.85,17.335 141.183,17.5017 144.5,18C 170.5,30.3333 196.5,42.6667 222.5,55C 226.894,58.0684 229.728,62.235 231,67.5C 236.872,93.8622 242.872,120.196 249,146.5C 249.61,150.236 249.277,153.903 248,157.5C 230.333,179.833 212.667,202.167 195,224.5C 192.441,227.531 189.274,229.698 185.5,231C 154.5,231.667 123.5,231.667 92.5,231C 88.7257,229.698 85.559,227.531 83,224.5C 66.9068,203.984 50.5734,183.651 34,163.5C 27.7798,155.497 26.7798,146.83 31,137.5C 36.6667,113.167 42.3333,88.8333 48,64.5C 49.7735,59.7271 52.9402,56.2271 57.5,54C 83.2576,41.7854 108.924,29.6188 134.5,17.5 Z"/></g>
+<g><path style="opacity:1" fill="#346de5" d="M 134.5,24.5 C 139.08,24.1134 143.414,24.9468 147.5,27C 171.045,38.606 194.712,49.9393 218.5,61C 222.491,63.7785 224.658,67.6119 225,72.5C 229.528,94.2768 234.528,115.943 240,137.5C 241.168,142.482 241.835,147.482 242,152.5C 241.439,154.725 240.439,156.725 239,158.5C 222.427,178.651 206.093,198.984 190,219.5C 188.269,221.617 186.102,223.117 183.5,224C 153.5,224.667 123.5,224.667 93.5,224C 73.0249,201.215 53.8582,177.382 36,152.5C 41.3608,123.356 47.6941,94.3556 55,65.5C 56.5,64 58,62.5 59.5,61C 84.8363,49.3308 109.836,37.1641 134.5,24.5 Z"/></g>
+<g><path style="opacity:1" fill="#fafbfe" d="M 133.5,45.5 C 137.167,45.5 140.833,45.5 144.5,45.5C 144.5,52.8333 144.5,60.1667 144.5,67.5C 158.146,68.9079 169.979,74.2412 180,83.5C 186.083,79.5376 191.917,75.2043 197.5,70.5C 199.493,72.6655 201.327,74.9989 203,77.5C 203.749,78.635 203.583,79.635 202.5,80.5C 197.179,84.489 192.179,88.8223 187.5,93.5C 194.894,105.411 198.061,118.411 197,132.5C 198.785,133.24 200.618,133.907 202.5,134.5C 203.471,131.879 204.804,129.546 206.5,127.5C 212.363,132.529 217.697,138.029 222.5,144C 222.355,144.772 222.022,145.439 221.5,146C 214.573,148.476 207.573,150.643 200.5,152.5C 200.5,149.833 200.5,147.167 200.5,144.5C 198.208,144.756 196.041,144.423 194,143.5C 188.976,155.86 180.976,165.86 170,173.5C 170.384,176.309 171.384,178.975 173,181.5C 174.897,179.984 177.064,179.317 179.5,179.5C 178.903,187.153 178.403,194.82 178,202.5C 177.439,203.022 176.772,203.355 176,203.5C 169.677,199.182 163.344,194.848 157,190.5C 156.312,189.668 156.479,189.002 157.5,188.5C 159.332,187.752 160.999,186.752 162.5,185.5C 161.42,183.004 160.086,180.67 158.5,178.5C 145.627,183.814 132.794,183.814 120,178.5C 118.833,180.833 117.667,183.167 116.5,185.5C 117.912,186.806 119.579,187.64 121.5,188C 122.451,188.718 122.617,189.551 122,190.5C 115.505,195.521 108.671,199.854 101.5,203.5C 100.745,195.178 100.078,186.845 99.5,178.5C 101.816,179.36 104.149,179.86 106.5,180C 107.627,178.247 108.627,176.413 109.5,174.5C 97.8509,166.691 89.3509,156.358 84,143.5C 81.9592,144.423 79.7925,144.756 77.5,144.5C 77.8333,147.167 78.1667,149.833 78.5,152.5C 71.0621,150.856 63.7288,148.689 56.5,146C 55.9781,145.439 55.6448,144.772 55.5,144C 60.3409,138.232 65.6742,132.899 71.5,128C 72.3317,127.312 72.9984,127.479 73.5,128.5C 74.3094,130.071 74.6427,131.738 74.5,133.5C 76.7925,133.756 78.9592,133.423 81,132.5C 80.115,118.45 83.2817,105.45 90.5,93.5C 85.5084,88.6769 80.3418,84.0102 75,79.5C 75.7298,75.4517 77.8965,72.6183 81.5,71C 87.0109,75.1809 92.5109,79.3475 98,83.5C 108.046,74.2274 119.879,68.8941 133.5,67.5C 133.5,60.1667 133.5,52.8333 133.5,45.5 Z"/></g>
+<g><path style="opacity:0.882" fill="#000000" d="M 858.5,74.5 C 867.424,74.3534 871.257,78.6868 870,87.5C 867.185,93.1691 862.685,95.0024 856.5,93C 850.261,88.7034 849.261,83.3701 853.5,77C 855.315,76.2432 856.981,75.4098 858.5,74.5 Z"/></g>
+<g><path style="opacity:1" fill="#356ee5" d="M 127.5,79.5 C 129.5,79.5 131.5,79.5 133.5,79.5C 133.666,89.1724 133.5,98.8391 133,108.5C 132.275,109.059 131.442,109.392 130.5,109.5C 122.292,104.225 114.625,98.2248 107.5,91.5C 113.265,85.9526 119.932,81.9526 127.5,79.5 Z"/></g>
+<g><path style="opacity:1" fill="#356de5" d="M 144.5,79.5 C 154.716,80.2764 163.382,84.2764 170.5,91.5C 163.172,97.9916 155.672,104.325 148,110.5C 147,109.833 146,109.167 145,108.5C 144.5,98.8391 144.334,89.1724 144.5,79.5 Z"/></g>
+<g><path style="opacity:0.928" fill="#000000" d="M 423.5,83.5 C 424.833,83.5 426.167,83.5 427.5,83.5C 427.5,88.8333 427.5,94.1667 427.5,99.5C 433.833,99.5 440.167,99.5 446.5,99.5C 446.5,104.167 446.5,108.833 446.5,113.5C 440.167,113.5 433.833,113.5 427.5,113.5C 427.13,121.903 427.63,130.236 429,138.5C 430.779,140.764 433.113,142.097 436,142.5C 439.478,141.671 442.978,141.004 446.5,140.5C 446.896,144.375 447.562,148.208 448.5,152C 448.095,152.945 447.428,153.612 446.5,154C 438.116,156.922 429.782,156.922 421.5,154C 415.996,151.16 412.829,146.66 412,140.5C 411.5,122.17 411.333,103.836 411.5,85.5C 415.733,85.4613 419.733,84.7947 423.5,83.5 Z"/></g>
+<g><path style="opacity:0.918" fill="#000000" d="M 311.5,98.5 C 321.347,97.9802 331.014,98.9802 340.5,101.5C 341.921,120.529 341.754,139.529 340,158.5C 337.742,166.389 332.575,171.222 324.5,173C 314.057,175.006 303.724,174.506 293.5,171.5C 294.111,166.892 295.111,162.392 296.5,158C 303.028,159.529 309.694,160.196 316.5,160C 322.554,158.957 325.054,155.457 324,149.5C 303.472,154.648 292.305,146.648 290.5,125.5C 291.084,111.263 298.084,102.263 311.5,98.5 Z M 316.5,111.5 C 319.119,111.232 321.619,111.565 324,112.5C 324.167,116.5 324.333,120.5 324.5,124.5C 327.333,136.731 323,140.564 311.5,136C 307.355,130.681 306.522,124.848 309,118.5C 310.767,115.228 313.267,112.895 316.5,111.5 Z"/></g>
+<g><path style="opacity:0.94" fill="#000000" d="M 364.5,98.5 C 371.175,98.3337 377.842,98.5004 384.5,99C 391.702,100.869 396.202,105.369 398,112.5C 398.5,126.163 398.667,139.829 398.5,153.5C 387.249,155.423 375.916,155.923 364.5,155C 353.152,151.144 348.985,143.31 352,131.5C 354.443,125.394 358.943,121.894 365.5,121C 371.528,120.83 377.528,120.33 383.5,119.5C 382.625,115.126 379.958,112.626 375.5,112C 369.805,111.623 364.305,112.456 359,114.5C 357.414,109.983 356.58,105.316 356.5,100.5C 359.373,100.198 362.039,99.531 364.5,98.5 Z M 372.5,131.5 C 376.167,131.5 379.833,131.5 383.5,131.5C 383.5,135.167 383.5,138.833 383.5,142.5C 378.728,143.929 374.061,143.595 369.5,141.5C 366.482,136.899 367.482,133.565 372.5,131.5 Z"/></g>
+<g><path style="opacity:0.928" fill="#000000" d="M 472.5,98.5 C 497.203,96.5548 507.87,107.888 504.5,132.5C 493.167,132.5 481.833,132.5 470.5,132.5C 470.79,136.961 473.123,139.795 477.5,141C 479.847,141.436 482.181,141.936 484.5,142.5C 489.581,141.61 494.581,140.776 499.5,140C 500.861,144.362 501.528,148.862 501.5,153.5C 491.612,156.456 481.612,156.956 471.5,155C 458.543,150.518 452.543,141.352 453.5,127.5C 453.103,113.266 459.436,103.599 472.5,98.5 Z M 477.5,111.5 C 483.988,111.484 487.988,114.651 489.5,121C 483.175,121.5 476.842,121.666 470.5,121.5C 470.873,116.742 473.206,113.409 477.5,111.5 Z"/></g>
+<g><path style="opacity:0.926" fill="#000000" d="M 605.5,98.5 C 612.175,98.3337 618.842,98.5004 625.5,99C 635.288,101.791 640.122,108.291 640,118.5C 640.5,130.162 640.667,141.829 640.5,153.5C 628.91,155.397 617.243,155.897 605.5,155C 594.473,151.455 590.306,143.955 593,132.5C 595.154,125.994 599.654,122.161 606.5,121C 612.491,120.501 618.491,120.334 624.5,120.5C 624.064,115.564 621.397,112.731 616.5,112C 610.805,111.623 605.305,112.456 600,114.5C 598.627,109.928 597.794,105.261 597.5,100.5C 600.373,100.198 603.039,99.531 605.5,98.5 Z M 613.5,131.5 C 617.167,131.5 620.833,131.5 624.5,131.5C 624.5,135.167 624.5,138.833 624.5,142.5C 619.728,143.929 615.061,143.595 610.5,141.5C 607.462,136.989 608.462,133.656 613.5,131.5 Z"/></g>
+<g><path style="opacity:0.925" fill="#000000" d="M 742.5,98.5 C 749.175,98.3337 755.842,98.5004 762.5,99C 771.815,101.649 776.649,107.816 777,117.5C 777.5,129.495 777.667,141.495 777.5,153.5C 766.244,155.386 754.911,155.886 743.5,155C 731.751,152.02 727.251,144.52 730,132.5C 732.154,125.994 736.654,122.161 743.5,121C 749.491,120.501 755.491,120.334 761.5,120.5C 761.064,115.564 758.397,112.731 753.5,112C 747.826,111.696 742.326,112.529 737,114.5C 735.627,109.928 734.794,105.261 734.5,100.5C 737.373,100.198 740.039,99.531 742.5,98.5 Z M 750.5,131.5 C 754.167,131.5 757.833,131.5 761.5,131.5C 761.5,135.167 761.5,138.833 761.5,142.5C 757.128,143.885 752.795,143.718 748.5,142C 744.299,137.629 744.966,134.129 750.5,131.5 Z"/></g>
+<g><path style="opacity:0.945" fill="#000000" d="M 802.5,98.5 C 832.848,95.8694 845.348,109.536 840,139.5C 837.5,147.333 832.333,152.5 824.5,155C 818.472,155.641 812.472,155.474 806.5,154.5C 806.5,160.833 806.5,167.167 806.5,173.5C 801.167,173.5 795.833,173.5 790.5,173.5C 790.333,149.498 790.5,125.498 791,101.5C 794.917,100.439 798.751,99.4392 802.5,98.5 Z M 806.5,112.5 C 818.841,110.485 824.841,115.652 824.5,128C 824.34,140.262 818.34,144.429 806.5,140.5C 806.5,131.167 806.5,121.833 806.5,112.5 Z"/></g>
+<g><path style="opacity:0.919" fill="#000000" d="M 509.5,99.5 C 515.5,99.5 521.5,99.5 527.5,99.5C 529.363,110.955 531.863,122.288 535,133.5C 538.352,122.28 541.186,110.947 543.5,99.5C 547.833,99.5 552.167,99.5 556.5,99.5C 558.225,110.401 560.892,121.068 564.5,131.5C 567.793,120.994 570.46,110.328 572.5,99.5C 578.167,99.5 583.833,99.5 589.5,99.5C 584.799,118.104 578.799,136.271 571.5,154C 567.129,154.828 562.795,154.661 558.5,153.5C 555.493,144.813 552.493,136.146 549.5,127.5C 546.671,136.14 543.838,144.806 541,153.5C 536.55,154.8 532.05,154.8 527.5,153.5C 520.497,135.824 514.497,117.824 509.5,99.5 Z"/></g>
+<g><path style="opacity:0.917" fill="#000000" d="M 645.5,99.5 C 651.425,99.1918 657.259,99.5251 663,100.5C 665.869,111.773 669.536,122.773 674,133.5C 677.886,122.345 681.053,111.011 683.5,99.5C 689.167,99.5 694.833,99.5 700.5,99.5C 694.611,121.996 686.445,143.663 676,164.5C 669.118,173.048 660.284,175.881 649.5,173C 647.616,172.784 645.949,172.117 644.5,171C 645.942,166.959 646.942,162.792 647.5,158.5C 651.796,159.463 656.129,159.629 660.5,159C 662.958,157.213 664.624,154.879 665.5,152C 657.154,135.128 650.488,117.628 645.5,99.5 Z"/></g>
+<g><path style="opacity:0.95" fill="#000000" d="M 852.5,99.5 C 857.833,99.5 863.167,99.5 868.5,99.5C 868.5,117.833 868.5,136.167 868.5,154.5C 863.167,154.5 857.833,154.5 852.5,154.5C 852.5,136.167 852.5,117.833 852.5,99.5 Z"/></g>
+<g><path style="opacity:1" fill="#386ee5" d="M 99.5,100.5 C 107.134,105.665 114.468,111.332 121.5,117.5C 122.833,119.167 122.833,120.833 121.5,122.5C 112.581,125.153 103.581,127.486 94.5,129.5C 92.1812,119.117 93.8478,109.45 99.5,100.5 Z"/></g>
+<g><path style="opacity:1" fill="#386fe5" d="M 177.5,100.5 C 184.058,109.086 186.058,118.752 183.5,129.5C 174.476,127.494 165.476,125.328 156.5,123C 155.24,121.186 155.24,119.353 156.5,117.5C 163.753,112.054 170.753,106.387 177.5,100.5 Z"/></g>
+<g><path style="opacity:1" fill="#4173e6" d="M 135.5,116.5 C 141.755,115.261 145.422,117.761 146.5,124C 144.602,131.278 140.269,133.111 133.5,129.5C 130.544,124.611 131.211,120.278 135.5,116.5 Z"/></g>
+<g><path style="opacity:1" fill="#386fe5" d="M 120.5,134.5 C 122.5,134.5 124.5,134.5 126.5,134.5C 123.684,144.464 119.517,153.797 114,162.5C 105.956,157.595 100.123,150.762 96.5,142C 96.9054,141.055 97.572,140.388 98.5,140C 105.962,138.134 113.295,136.301 120.5,134.5 Z"/></g>
+<g><path style="opacity:1" fill="#386ee5" d="M 152.5,133.5 C 161.379,136.092 170.379,138.259 179.5,140C 180.428,140.388 181.095,141.055 181.5,142C 178.209,150.792 172.542,157.626 164.5,162.5C 159.86,154.421 155.693,146.087 152,137.5C 151.421,136.072 151.588,134.738 152.5,133.5 Z"/></g>
+<g><path style="opacity:1" fill="#376ee5" d="M 136.5,141.5 C 138.604,141.201 140.604,141.534 142.5,142.5C 146.737,150.968 150.403,159.635 153.5,168.5C 148.384,169.489 143.218,170.156 138,170.5C 133.215,170.678 128.715,169.678 124.5,167.5C 129.059,159.051 133.059,150.384 136.5,141.5 Z"/></g>
+</svg>

content/bn/blog/_posts/2024-05-09-gateway-api-v1.1/index.md

@@ -0,0 +1,255 @@
+---
+layout: blog
+title: "গেটওয়ে API v1.1: সার্ভিস মেশ, GRPCRoute, এবং আরো অনেক কিছু"
+date: 2024-05-09T09:00:00-08:00
+slug: gateway-api-v1-1
+author: >
+  [Richard Belleville](https://github.com/gnossen) (Google),
+  [Frank Budinsky](https://github.com/frankbu) (IBM),
+  [Arko Dasgupta](https://github.com/arkodg) (Tetrate),
+  [Flynn](https://github.com/kflynn) (Buoyant),
+  [Candace Holman](https://github.com/candita) (Red Hat),
+  [John Howard](https://github.com/howardjohn) (Solo.io),
+  [Christine Kim](https://github.com/xtineskim) (Isovalent),
+  [Mattia Lavacca](https://github.com/mlavacca) (Kong),
+  [Keith Mattix](https://github.com/keithmattix) (Microsoft),
+  [Mike Morris](https://github.com/mikemorris) (Microsoft),
+  [Rob Scott](https://github.com/robscott) (Google),
+  [Grant Spence](https://github.com/gcs278) (Red Hat),
+  [Shane Utt](https://github.com/shaneutt) (Kong),
+  [Gina Yeh](https://github.com/ginayeh) (Google),
+  and other review and release note contributors
+---
+
+![গেটওয়ে API লোগো](gateway-api-logo.svg)
+
+গত অক্টোবরে গেটওয়ে API-এর
+GA রিলিজের পর, কুবারনেটিস SIG নেটওয়ার্ক [গেটওয়ে API](https://gateway-api.sigs.k8s.io/)-এর v1.1
+রিলিজ ঘোষণা করতে পেরে আনন্দিত। এই রিলিজে, বেশ কিছু ফিচার
+_Standard Channel_ (GA)-তে গ্র্যাজুয়েট হচ্ছে, বিশেষত সার্ভিস মেশ এবং GRPCRoute-এর জন্য
+সাপোর্ট সহ। আমরা কিছু নতুন এক্সপেরিমেন্টাল ফিচারও প্রবর্তন করছি, যার মধ্যে
+সেশনের স্থিরতা এবং ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন।
+
+## নতুন কি
+
+### স্ট্যান্ডার্ড থেকে গ্র্যাজুয়েট
+
+এই রিলিজে চারটি অধীর আগ্রহে প্রতীক্ষিত ফিচার স্ট্যান্ডার্ডে গ্র্যাজুয়েট অন্তর্ভুক্ত রয়েছে।
+এর মানে এগুলো আর পরীক্ষামূলক ধারণা নয়; স্ট্যান্ডার্ড রিলিজ
+চ্যানেলে অন্তর্ভুক্তি API সারফেসের উপর হাই লেভেলের আস্থা নির্দেশ করে এবং
+ব্যাকওয়ার্ড কম্প্যাটিবিলিটির গ্যারান্টি প্রদান করে। অবশ্যই, অন্য যেকোন
+কুবারনেটিস API-এর মতো, স্ট্যান্ডার্ড চ্যানেল ফিচারগুলি সময়ের সাথে সাথে
+ব্যাকওয়ার্ড-কম্প্যাটিবিলিটির সংযোজনের সাথে বিকশিত হতে পারে এবং আমরা অবশ্যই ভবিষ্যতে
+এই নতুন ফিচারগুলিতে আরও রিফাইনমেন্ট এবং উন্নতি আশা করি।
+এই সবগুলি কীভাবে কাজ করে সে সম্পর্কে আরও তথ্যের জন্য,
+[গেটওয়ে API ভার্শনিং পলিসি](https://gateway-api.sigs.k8s.io/concepts/versioning/) দেখুন।
+
+#### [সার্ভিস মেশ সাপোর্ট](https://gateway-api.sigs.k8s.io/mesh/)
+
+সার্ভিস মেশ সাপোর্ট গেটওয়ে APIতে সার্ভিস মেশ ব্যবহারকারীদের ইনগ্রেস ট্র্যাফিক এবং মেশ ট্র্যাফিক
+পরিচালনা করতে, একই পলিসি এবং রাউটিং ইন্টারফেসগুলি পুনরায় ব্যবহার করতে একই API
+ব্যবহার করতে দেয়। গেটওয়ে API v1.1-এ, রুটগুলিতে (যেমন HTTPRoute) এখন 'parentRef' হিসাবে
+একটি সার্ভিস থাকতে পারে, নির্দিষ্ট সার্ভিসগুলিতে ট্র্যাফিক কীভাবে আচরণ করে তা নিয়ন্ত্রণ করতে।
+আরও তথ্যের জন্য,
+[গেটওয়ে API সার্ভিস মেশ ডকুমেন্টেশন] (https://gateway-api.sigs.k8s.io/mesh/)
+পড়ুন বা 
+[গেটওয়ে API বাস্তবায়নের তালিকা] (https://gateway-api.sigs.k8s.io/implementations/#service-mesh-implementation-status) দেখুন।
+
+উদাহরণস্বরূপ, কেউ একটি HTTPRoute দিয়ে একটি অ্যাপ্লিকেশনের কল গ্রাফের গভীরে
+একটি ওয়ার্কলোডের একটি canary স্থাপনার কাজ করতে পারে:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: color-canary
+  namespace: faces
+spec:
+  parentRefs:
+    - name: color
+      kind: Service
+      group: ""
+      port: 80
+  rules:
+  - backendRefs:
+    - name: color
+      port: 80
+      weight: 50
+    - name: color2
+      port: 80
+      weight: 50
+```
+
+এটি মূল `color` সার্ভিস এবং `color2` সার্ভিসটির মধ্যে `faces` নেমস্পেস এর
+`color` সার্ভিসটিতে প্রেরিত ট্র্যাফিককে 50/50 বিভক্ত করবে, একটি পোর্টেবল
+কনফিগারেশন ব্যবহার করে যা এক মেশ থেকে অন্য মেশে সরানো সহজ।
+
+#### [GRPCRoute](https://gateway-api.sigs.k8s.io/guides/grpc-routing/)
+
+আপনি যদি ইতিমধ্যে GRPCRoute এর পরীক্ষামূলক ভার্সনটি ব্যবহার করে থাকেন তবে আমরা
+GRPCRoute স্ট্যান্ডার্ড চ্যানেল ভার্সনে আপগ্রেড করা বন্ধ রাখার পরামর্শ দিচ্ছি যতক্ষণ না আপনি যে কন্ট্রোলারগুলি
+ব্যবহার করছেন তা GRPCRoute v1 সমর্থন করার জন্য আপডেট করা হয়। ততক্ষণ পর্যন্ত,
+GRPCRoute-এর v1.1-এ পরীক্ষামূলক চ্যানেল ভার্সনে আপগ্রেড করা নিরাপদ
+যা v1alpha2 এবং v1 API ভার্সন উভয়ই অন্তর্ভুক্ত করে।
+
+#### [ParentReference Port](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.ParentReference)
+
+`port` ফিল্ডটি ParentReference এ যুক্ত করা হয়েছিল, আপনাকে গেটওয়ে লিসেনার,
+সার্ভিস বা অন্যান্য প্যারেন্ট রিসোর্সগুলিতে রিসোর্সগুলি সংযুক্ত করার অনুমতি দেয়
+(বাস্তবায়নের উপর নির্ভর করে)। একটি পোর্টের সাথে বাইন্ডিং আপনাকে
+একবারে একাধিক লিসেনার্সের সাথে অ্যাটাচ করতে দেয়।
+
+উদাহরণস্বরূপ, আপনি লিসেনারের `name` ফিল্ডের পরিবর্তে লিসেনার `port` দ্বারা নির্দিষ্ট হিসাবে
+গেটওয়ের এক বা একাধিক নির্দিষ্ট লিসেনারের সাথে একটি HTTPRoute সংযুক্ত করতে পারেন।
+
+আরও তথ্যের জন্য, দেখুন
+[গেটওয়েতে সংযুক্ত করা হচ্ছে](https://gateway-api.sigs.k8s.io/api-types/httproute/#attaching-to-gateways).
+
+#### [কনফর্মেন্স প্রোফাইল এবং রিপোর্ট](https://gateway-api.sigs.k8s.io/concepts/conformance/#conformance-profiles)
+
+কনফর্মেন্স রিপোর্ট API `mode` ফিল্ড (ইমপ্লিমেন্টেশনের কাজের মোড নির্দিষ্ট করার
+উদ্দেশ্যে) এবং `gatewayAPIChannel` (স্ট্যান্ডার্ড বা এক্সপেরিমেন্টাল)
+দিয়ে প্রসারিত করা হয়েছে। `gatewayAPIVersion` এবং `gatewayAPIChannel`
+এখন টেস্টিং ফলাফলের সংক্ষিপ্ত বিবরণ সহ স্যুট মেশিনারি দ্বারা
+স্বয়ংক্রিয়ভাবে পূরণ করা হয়। প্রতিবেদনগুলি আরও স্ট্রাকচারড উপায়ে পুনর্গঠিত হয়েছে এবং
+ইমপ্লিমেন্টেশনগুলিতে এখন টেস্টগুলি কীভাবে চালানো হবে সে সম্পর্কে তথ্য যুক্ত করতে পারে এবং
+রিপ্রোডাকশন পদক্ষেপগুলি সরবরাহ করতে পারে।
+
+### এক্সপেরিমেন্টাল চ্যানেলে নতুন সংযোজন
+
+#### [গেটওয়ে ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন](https://gateway-api.sigs.k8s.io/geps/gep-91/)
+
+গেটওয়েগুলি এখন `tls` এর মধ্যে একটি নতুন `frontendValidation` ফিল্ড প্রবর্তন করে প্রতিটি
+গেটওয়ে লিস্টেনারের জন্য ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন কনফিগার করতে পারে।
+এই ফিল্ডটি CA সার্টিফিকেটগুলির একটি তালিকা কনফিগার করা সমর্থন করে যা ক্লায়েন্ট দ্বারা উপস্থাপিত
+সার্টিফিকেটগুলি যাচাই করার জন্য ট্রাস্ট অ্যাঙ্কর হিসাবে ব্যবহার করা যেতে পারে।
+
+নিম্নলিখিত উদাহরণটি দেখায় যে কীভাবে `foo-example-com-ca-cert`
+ConfigMap-এ সঞ্চিত CACertificate-টি `foo-https` গেটওয়ে লিস্টেনারের সাথে সংযুক্ত ক্লায়েন্টদের
+দ্বারা উপস্থাপিত সার্টিফিকেটগুলি যাচাই করতে ব্যবহার করা যেতে পারে।
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1
+kind: Gateway
+metadata:
+  name: client-validation-basic
+spec:
+  gatewayClassName: acme-lb
+  listeners:
+    name: foo-https
+    protocol: HTTPS
+    port: 443
+    hostname: foo.example.com
+  tls:
+    certificateRefs:
+      kind: Secret
+      group: ""
+      name: foo-example-com-cert
+    frontendValidation:
+      caCertificateRefs:
+        kind: ConfigMap
+        group: ""
+        name: foo-example-com-ca-cert
+```
+
+#### [সেশন পার্সিস্টেন্স এবং BackendLBPolicy (Session Persistence and BackendLBPolicy)](https://gateway-api.sigs.k8s.io/geps/gep-1619/)
+
+সার্ভিস-লেভেলের কনফিগারেশনের জন্য একটি নতুন পলিসি
+([BackendLBPolicy](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.BackendLBPolicy))
+এবং রুট-লেভেলের কনফিগারেশনের জন্য HTTPRoute এবং GRPCRoute এর মধ্যে ফিল্ড হিসাবে গেটওয়ে API-তে
+[সেশন পার্সিস্টেন্স](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.SessionPersistence)
+ইন্ট্রোডিউসড করা হচ্ছে। BackendLBPolicy এবং রুট-লেভেলের
+API-গুলি সেশন টাইমআউট, সেশনের নাম, সেশনের ধরণ এবং কুকি লাইফটাইম টাইপ সহ
+একই সেশন পার্সিস্টেন্স কনফিগারেশন সরবরাহ করে।
+
+নীচে `BackendLBPolicy` এর একটি উদাহরণ কনফিগারেশন রয়েছে যা `foo` সার্ভিসের জন্য কুকি-বেসড
+সেশন পার্সিস্টেন্স এনাবল করে। এটি সেশনের নামটি `foo-session` এ সেট করে,
+অ্যাবসুলুট এবং আইডিএল টাইমআউটসগুলি ডিফাইন করে এবং কুকিটিকে সেশন
+কুকি হিসাবে কনফিগার করে:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1alpha2
+kind: BackendLBPolicy
+metadata:
+  name: lb-policy
+  namespace: foo-ns
+spec:
+  targetRefs:
+  - group: core
+    kind: service
+    name: foo
+  sessionPersistence:
+    sessionName: foo-session
+    absoluteTimeout: 1h
+    idleTimeout: 30m
+    type: Cookie
+    cookieConfig:
+      lifetimeType: Session
+```
+
+### বাকি সব
+
+#### [TLS টার্মিনোলজি ক্ল্যারিফিকেশন](https://gateway-api.sigs.k8s.io/geps/gep-2907/)
+
+API জুড়ে আমাদের TLS টার্মিনোলজিকে আরও সামঞ্জস্যপূর্ণ করার বিস্তৃত লক্ষ্যের
+অংশ হিসাবে, আমরা BackendTLSPolicy-তে কিছু ব্রেকিং পরিবর্তন ইন্ট্রোডিউসড করেছি।
+এর ফলে একটি নতুন API ভার্সন (v1alpha3) তৈরি হয়েছে এবং ভার্সন আপগ্রেড সঠিকভাবে পরিচালনা
+করার জন্য এই নীতির যে কোনও এক্সিস্টিং ইমপ্লিমেন্টেশনের প্রয়োজন হবে, যেমন
+ডেটা ব্যাক আপ করে এবং এই নতুন ভার্সনটি ইনস্টল করার আগে v1alpha2
+ভার্সনটি আনইনস্টল করতে হবে।
+
+v1alpha2 BackendTLSPolicy ফিল্ড-ত্রর যে কোনও রেফারেন্স v1alpha3 এ আপডেট করতে হবে।
+ফিল্ডগুলিতে নির্দিষ্ট পরিবর্তনগুলির মধ্যে রয়েছে:
+
+- `targetRef` BackendTLSPolicy-কে একাধিক লক্ষ্যবস্তুর সাথে সংযুক্ত করার অনুমতি দেওয়ার
+  জন্য `targetRefs` হয়ে যায়
+- `tls`  হয়ে যায় `validation`
+- `tls.caCertRefs` হয়ে যায় `validation.caCertificateRefs`
+- `tls.wellKnownCACerts` হয়ে যায় `validation.wellKnownCACertificates`
+
+এই রিলিজে অন্তর্ভুক্ত পরিবর্তনগুলির সম্পূর্ণ তালিকার জন্য, দয়া করে
+[v1.1.0 রিলিজ নোটগুলি](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.1.0) দেখুন।
+
+## গেটওয়ে API ব্যাকগ্রাউন্ড
+
+গেটওয়ে API-এর ধারণাটি প্রাথমিকভাবে 2019 KubeCon San Diego-তে
+Ingress API-এর পরবর্তী প্রজন্ম হিসাবে [প্রপোজড](https://youtu.be/Ne9UJL6irXY?si=wgtC9w8PMB5ZHil2)
+করা হয়েছিল। তার পর থেকে,
+[কুবারনেটিস ইতিহাসের সবচেয়ে সহযোগী API](https://www.youtube.com/watch?v=V3Vu_FWb4l4)
+হয়ে ওঠার জন্য একটি অবিশ্বাস্য কমিউনিটি গঠিত হয়েছে।
+এখন পর্যন্ত 200 জনেরও বেশি লোক এই API-তে অবদান রেখেছে এবং এই সংখ্যাটি বাড়ছে।
+
+রক্ষণাবেক্ষণকারীরা গেটওয়ে API তে অবদান রেখেছেন রিপোসিটোরি তে কমিট,
+ডিসকাশন, আইডিয়া বা সাধারণ সহায়তার আকারে এমন প্রত্যেককে ধন্যবাদ জানাতে চান।
+আমরা সত্যিকার অর্থেই এই নিবেদিত ও সক্রিয় কমিউনিটির সাপোর্ট ছাড়া এতদূর
+আসতে পারতাম না।
+
+## চেষ্টা করে দেখুন
+
+অন্যান্য কুবারনেটিস API-গুলির বিপরীতে, গেটওয়ে API-এর সর্বশেষ ভার্সন পেতে আপনাকে
+কুবারনেটিসের সর্বশেষ ভার্সনে আপগ্রেড করতে হবে না। যতক্ষণ না আপনি কুবারনেটিস 1.26
+বা তার পরের টা চালাচ্ছেন, আপনি গেটওয়ে API-এর এই ভার্সনটি দিয়ে উঠতে এবং
+চালাতে সক্ষম হবেন।
+
+API ব্যবহার করতে, আমাদের [শুরু করার গাইড](https://gateway-api.sigs.k8s.io/guides/) অনুসরণ করুন।
+
+## যুক্ত হোন
+
+ইনগ্রেস এবং সার্ভিস মেশ উভয়ের জন্য কুবারনেটিস রাউটিং API-গুলির ভবিষ্যতকে সংজ্ঞায়িত করতে
+এবং সহায়তা করার প্রচুর সুযোগ রয়েছে।
+
+* কোন ইউজ-কেস সম্বোধন করা যেতে পারে তা দেখতে [ব্যবহারকারী গাইডগুলি](https://gateway-api.sigs.k8s.io/guides) দেখুন।
+* [বিদ্যমান গেটওয়ে কন্ট্রোলারগুলির](https://gateway-api.sigs.k8s.io/implementations/) মধ্যে একটি ব্যবহার করে দেখুন।
+* অথবা [কমিউনিটিতে আমাদের সাথে যোগ দিন](https://gateway-api.sigs.k8s.io/contributing/)
+  এবং একসাথে গেটওয়ে API-এর ভবিষ্যত গড়ে তুলতে আমাদের সহায়তা করুন!
+
+## রিলেটেড কুবারনেটিস ব্লগ আর্টিকেলস
+
+* [গেটওয়ে API v1.0 এ নতুন এক্সপেরিমেন্টাল ফিচারস](/blog/2023/11/28/gateway-api-ga/)
+  11/2023
+* [গেটওয়ে API v1.0: GA রিলিজ](/blog/2023/10/31/gateway-api-ga/)
+  10/2023
+* [ingress2gateway ইন্ট্রোডিউসিং করা; গেটওয়ে API-তে আপগ্রেড সিম্পলিফাই করা হচ্ছে](/blog/2023/10/25/introducing-ingress2gateway/)
+  10/2023
+* [গেটওয়ে API v0.8.0: ইন্ট্রোডিউসিং সার্ভিস মেশ সাপোর্ট](/blog/2023/08/29/gateway-api-v0-8/)
+  08/2023

content/bn/docs/concepts/extend-kubernetes/compute-storage-net/_index.md

@@ -35,7 +35,7 @@ no_list: true
 
 * [নেটওয়ার্ক প্লাগইন](/bn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 
-  একটি নেটওয়ার্ক প্লাগইন কুবারনেটিসকে বিভিন্ন নেটওয়ার্কিং টপোলজি এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেয়।
+  নেটওয়ার্ক প্লাগইন কুবারনেটিসকে বিভিন্ন নেটওয়ার্কিং টপোলজি এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেয়।
   আপনার কুবারনেটিস ক্লাস্টারের একটি _নেটওয়ার্ক প্লাগইন_ প্রয়োজন যাতে একটি কার্যকরী পড নেটওয়ার্ক থাকে 
   এবং কুবারনেটিস নেটওয়ার্ক মডেলের অন্যান্য দিকগুলোকে সাপোর্ট করতে পারে ৷
 

content/bn/docs/concepts/overview/_index.md

@@ -1,4 +1,7 @@
 ---
+# reviewers:
+#  - bgrant0607
+#  - mikedanese ( The list of approvers is not necessary for the localized version. However, it is included because it helps maintain a certain line break, which further aids in updating a file.That's why it's kept in comment form. )
 title: "ওভারভিউ"
 description: >
   কুবারনেটিস হল একটি পোর্টেবল, এক্সটেনসিবল, ওপেন সোর্স প্ল্যাটফর্ম যা কন্টেইনারাইজড ওয়ার্কলোড এবং সার্ভিসগুলি পরিচালনা করার জন্য, ঘোষণামূলক কনফিগারেশন এবং অটোমেশন উভয়কেই সহজতর করে। এটির একটি বড়, দ্রুত বর্ধনশীল ইকোসিস্টেম রয়েছে। কুবারনেটিস সার্ভিসগুলি, সাপোর্ট, এবং টুলস ব্যাপকভাবে সহজলভ্য।
@@ -19,75 +22,12 @@ no_list: true
 
 <!-- body -->
 
-কুবারনেটিস হল একটি পোর্টেবল, বর্ধনশীল, ওপেন সোর্স প্ল্যাটফর্ম যা কনটেইনারাইজড 
-ওয়ার্কলোড এবং পরিষেবাগুলি পরিচালনা করার জন্য, ঘোষণামূলক কনফিগারেশন এবং অটোমেশন উভয়কেই সহজতর করে। 
-এটির একটি বড়, দ্রুত বর্ধনশীল ইকোসিস্টেম রয়েছে। কুবারনেটিস পরিষেবাগুলি, সমর্থন, এবং সরঞ্জাম ব্যাপকভাবে সহজলভ্য।
-
 কুবারনেটিস নামটি গ্রীক থেকে এসেছে, যার অর্থ হেলমসম্যান বা পাইলট। 
 "K" এবং "s" এর মধ্যে আটটি অক্ষর গণনা করার ফলে একটি সংক্ষিপ্ত রূপ K8s। গুগল ২০১৪ সালে 
 কুবারনেটিস প্রজেক্টটি ওপেন সোর্স করেছে। কুবারনেটিস 
 [15 বছরেরও বেশি সময় ধরে Google-এর অভিজ্ঞতাকে](/blog/2015/04/borg-predecessor-to-kubernetes/) একত্রিত করেছে 
 যা কমিউনিটির সেরা আইডিয়া এবং অনুশীলনের সাথে স্কেলে উৎপাদন কাজের চাপ চালানোর।
 
-## অতিতে যাই
-
-চলুন অতিতে যেয়ে এক নজরে দেখে নেওয়া যাক কেন কুবারনেটিস এতটা কাজে লাগে। 
-
-![ডিপ্লয়মেন্টের বিবর্তন](/images/docs/Container_Evolution.svg)
-
-**ঐতিহ্যবাহী ডিপ্লয়মেন্টের যুগ:**
-প্রথম দিকে, সংস্থাগুলি ফিজিক্যাল সার্ভারগুলিতে অ্যাপ্লিকেশন চালাত। 
-একটি ফিজিক্যাল সার্ভারে অ্যাপ্লিকেশনের জন্য রিসোর্স সীমানা নির্ধারণ করার কোন উপায় ছিল না, 
-এবং এর ফলে রিসোর্স বরাদ্দ সমস্যা হয়েছে। উদাহরণস্বরূপ, যদি একটি ফিজিক্যাল সার্ভারে একাধিক অ্যাপ্লিকেশান চালিত হয়, 
-এমন উদাহরণ হতে পারে যেখানে একটি অ্যাপ্লিকেশন বেশিরভাগ সংস্থান গ্রহণ করবে, এবং ফলস্বরূপ, অন্যান্য অ্যাপ্লিকেশনগুলি কম পারফর্ম করবে। 
-এই জন্য একটি সমাধান একটি ভিন্ন ফিজিক্যাল সার্ভারে প্রতিটি অ্যাপ্লিকেশন চালানো হবে। 
-কিন্তু সম্পদের অব্যবহৃত হওয়ার কারণে এটির মাপকাঠিি ঠিক করা যায়নি এবং 
-অনেকগুলি ফিজিক্যাল সার্ভার বজায় রাখা সংস্থাগুলির জন্য ব্যয়বহুল ছিল।
-
-**ভার্চুয়ালাইজড ডিপ্লয়মেন্টর যুগ:**  একটি সমাধান হিসাবে, ভার্চুয়ালাইজেশন চালু করা হয়েছিল। এটি আপনাকে 
-একটি একক ফিজিক্যাল সার্ভারের CPU-তে একাধিক ভার্চুয়াল মেশিন (VMs) চালানো যায়। ভার্চুয়ালাইজেশন 
-অ্যাপ্লিকেশনগুলিকে VM-এর মধ্যে বিচ্ছিন্ন করার অনুমতি দেয় এবং একটি স্তরের নিরাপত্তা প্রদান করে 
-কারণ একটি অ্যাপ্লিকেশনের তথ্য অন্য অ্যাপ্লিকেশন দ্বারা অবাধে অ্যাক্সেস করা যায় না। 
- 
-ভার্চুয়ালাইজেশন একটি ফিজিক্যাল সার্ভারে রিসোর্সগুলির আরও ভালো ব্যবহারের অনুমতি দেয় এবং 
-আরও ভাল স্কেলেবিলিটির অনুমতি দেয় কারণ একটি অ্যাপ্লিকেশন সহজে যোগ বা আপডেট করা যায়, হার্ডওয়্যার খরচ কমায় 
-এবং আরও অনেক কিছু। ভার্চুয়ালাইজেশনের মাধ্যমে আপনি ডিসপোজেবল ভার্চুয়াল মেশিনের 
-একটি ক্লাস্টার হিসাবে ফিজিক্যাল সম্পদের একটি সেট উপস্থাপন করতে পারেন।
-
-প্রতিটি VM হল একটি সম্পূর্ণ মেশিন যা ভার্চুয়ালাইজড হার্ডওয়্যারের উপরে নিজস্ব অপারেটিং সিস্টেম 
-সহ সমস্ত উপাদান চালায়।
-
-**কন্টেইনার স্থাপনের যুগ:** কনটেইনারগুলি VM-এর মতোই, তবে অ্যাপ্লিকেশনগুলির 
-মধ্যে অপারেটিং সিস্টেম (OS) ভাগ করার জন্য তাদের শিথিল বিচ্ছিন্নতা বৈশিষ্ট্য রয়েছে৷ 
-অতএব, কন্টেইনারগুলোকে হালকা বলে মনে করা হয়। একটি VM-এর মতো, একটি কনটেইনারের 
-নিজস্ব ফাইল সিস্টেম, CPU ভাগ, মেমরি, প্রক্রিয়া স্থান এবং আরও অনেক কিছু রয়েছে। যেহেতু এগুলি 
-অন্তর্নিহিত অবকাঠামো থেকে আলাদা করা হয়েছে, তারা ক্লাউড এবং 
-OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্য।
-
-কন্টেইনারগুলো জনপ্রিয় হয়ে উঠেছে কারণ তারা অতিরিক্ত সুবিধা প্রদান করে, যেমন:
-
-* এজাইল (Agile) অ্যাপ্লিকেশন তৈরি এবং ডিপ্লয়মেন্টয়: ভিএম ইমেজ (VM Image) ব্যবহারের তুলনায় কন্টেইনার ইমেজ (Container Image) 
-  তৈরির সহজতা এবং দক্ষতা বেশি। 
-* ক্রমাগত বিকাশ, একীকরণ এবং ডিপ্লয়মেন্ট: নির্ভরযোগ্য এবং ঘন ঘন
-  কন্টেইনার ইমেজ তৈরি এবং ডিপ্লয়মেন্টের জন্য প্রদান করে দ্রুত এবং
-  দক্ষ রোলব্যাকের (ইমেজ অপরিবর্তনীয়তার কারণে) সাথে ।
-* ডেভ (Dev) এবং অপস (Ops) উদ্বেগের বিচ্ছেদ: বিল্ড/রিলিজের সময়ে
-  অ্যাপ্লিকেশন কন্টেইনার ইমেজ তৈরি করে ডিপ্লয়মেন্টের সময়ের তুলনায়,
-  ফলস্বরূপ অ্যাপ্লিকেশনগুলি অবকাঠামো থেকে বিচ্ছিন্ন হয়। 
-* পর্যবেক্ষণযোগ্যতা: শুধুমাত্র OS-স্তরের তথ্য এবং মেট্রিক্সই নয়, 
-  প্রয়োগের স্বাস্থ্য এবং অন্যান্য সংকেতও।
-* ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন জুড়ে পরিবেশগত সামঞ্জস্য: একটি 
-  ল্যাপটপে ক্লাউডের মতোই চলে।
-* ক্লাউড এবং ওএস ডিস্ট্রিবিউশন পোর্টেবিলিটি: উবুন্টু (Ubuntu), রেল (RHEL), কোরওস (CoreOS), অন-প্রিমিসেস (on-premises), 
-  প্রধান পাবলিক ক্লাউডসর উপর, এবং অন্য কোথাও চলে।
-* অ্যাপ্লিকেশন-কেন্দ্রিক ব্যবস্থাপনা: ভার্চুয়াল হার্ডওয়্যারে একটি OS চালানো থেকে 
-  লজিক্যাল রিসোর্স ব্যবহার করে একটি OS-এ একটি অ্যাপ্লিকেশন চালানো পর্যন্ত বিমূর্ততার স্তর বাড়ায়।
-* ঢিলেঢালাভাবে সংযুক্ত, বিতরণ করা, স্থিতিস্থাপক, মুক্ত মাইক্রো-পরিষেবা: অ্যাপ্লিকেশনগুলিকে 
-  ছোট, স্বাধীন টুকরোগুলিতে বিভক্ত করা হয় এবং গতিশীলভাবে স্থাপন ও পরিচালনা করা যায় – 
-  একটি বড় একক-উদ্দেশ্য মেশিনে চলমান একটি মনোলিথিক স্ট্যাক নয়।.
-* রিসোর্স আইসোলেশন: অনুমানযোগ্য অ্যাপ্লিকেশন কর্মক্ষমতা।
-* রিসোর্স ব্যবহার: উচ্চ দক্ষতা এবং ঘনত্ব।
-
 ## আপনার কেন কুবারনেটিস দরকার এবং এটি কী করতে পারে {#why-you-need-kubernetes-and-what-can-it-do}
 
 কন্টেইনারসমূহ অ্যাপ্লিকেশন একত্রকরণ  এবং চালানোর একটি ভালো উপায়৷ একটি উৎপাদন 
@@ -171,6 +111,71 @@ OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্
   আপনি A থেকে C পর্যন্ত কিভাবে যাবেন তা বিবেচ্য নয়। কেন্দ্রীভূত নিয়ন্ত্রণেরও প্রয়োজন নেই। এই
   সিস্টেমের ফলাফল যা ব্যবহার করা সহজ এবং আরও শক্তিশালী, মজবুত, স্থিতিস্থাপক এবং এক্সটেনসিবল।
 
+## কুবারনেটিসের জন্য ঐতিহাসিক প্রেক্ষাপট {#অতিতে-যাই}
+
+চলুন অতিতে যেয়ে এক নজরে দেখে নেওয়া যাক কেন কুবারনেটিস এতটা কাজে লাগে। 
+
+![ডিপ্লয়মেন্টের বিবর্তন](/images/docs/Container_Evolution.svg)
+
+**ঐতিহ্যবাহী ডিপ্লয়মেন্টের যুগ:**
+
+প্রথম দিকে, সংস্থাগুলি ফিজিক্যাল সার্ভারগুলিতে অ্যাপ্লিকেশন চালাত। 
+একটি ফিজিক্যাল সার্ভারে অ্যাপ্লিকেশনের জন্য রিসোর্স সীমানা নির্ধারণ করার কোন উপায় ছিল না, 
+এবং এর ফলে রিসোর্স বরাদ্দ সমস্যা হয়েছে। উদাহরণস্বরূপ, যদি একটি ফিজিক্যাল সার্ভারে একাধিক অ্যাপ্লিকেশান চালিত হয়, 
+এমন উদাহরণ হতে পারে যেখানে একটি অ্যাপ্লিকেশন বেশিরভাগ সংস্থান গ্রহণ করবে, এবং ফলস্বরূপ, অন্যান্য অ্যাপ্লিকেশনগুলি কম পারফর্ম করবে। 
+এই জন্য একটি সমাধান একটি ভিন্ন ফিজিক্যাল সার্ভারে প্রতিটি অ্যাপ্লিকেশন চালানো হবে। 
+কিন্তু সম্পদের অব্যবহৃত হওয়ার কারণে এটির মাপকাঠিি ঠিক করা যায়নি এবং 
+অনেকগুলি ফিজিক্যাল সার্ভার বজায় রাখা সংস্থাগুলির জন্য ব্যয়বহুল ছিল।
+
+**ভার্চুয়ালাইজড ডিপ্লয়মেন্টর যুগ:**  
+
+একটি সমাধান হিসাবে, ভার্চুয়ালাইজেশন চালু করা হয়েছিল। এটি আপনাকে 
+একটি একক ফিজিক্যাল সার্ভারের CPU-তে একাধিক ভার্চুয়াল মেশিন (VMs) চালানো যায়। ভার্চুয়ালাইজেশন 
+অ্যাপ্লিকেশনগুলিকে VM-এর মধ্যে বিচ্ছিন্ন করার অনুমতি দেয় এবং একটি স্তরের নিরাপত্তা প্রদান করে 
+কারণ একটি অ্যাপ্লিকেশনের তথ্য অন্য অ্যাপ্লিকেশন দ্বারা অবাধে অ্যাক্সেস করা যায় না। 
+ 
+ভার্চুয়ালাইজেশন একটি ফিজিক্যাল সার্ভারে রিসোর্সগুলির আরও ভালো ব্যবহারের অনুমতি দেয় এবং 
+আরও ভাল স্কেলেবিলিটির অনুমতি দেয় কারণ একটি অ্যাপ্লিকেশন সহজে যোগ বা আপডেট করা যায়, হার্ডওয়্যার খরচ কমায় 
+এবং আরও অনেক কিছু। ভার্চুয়ালাইজেশনের মাধ্যমে আপনি ডিসপোজেবল ভার্চুয়াল মেশিনের 
+একটি ক্লাস্টার হিসাবে ফিজিক্যাল সম্পদের একটি সেট উপস্থাপন করতে পারেন।
+
+প্রতিটি VM হল একটি সম্পূর্ণ মেশিন যা ভার্চুয়ালাইজড হার্ডওয়্যারের উপরে নিজস্ব অপারেটিং সিস্টেম 
+সহ সমস্ত উপাদান চালায়।
+
+**কন্টেইনার স্থাপনের যুগ:** 
+
+কনটেইনারগুলি VM-এর মতোই, তবে অ্যাপ্লিকেশনগুলির 
+মধ্যে অপারেটিং সিস্টেম (OS) ভাগ করার জন্য তাদের শিথিল বিচ্ছিন্নতা বৈশিষ্ট্য রয়েছে৷ 
+অতএব, কন্টেইনারগুলোকে হালকা বলে মনে করা হয়। একটি VM-এর মতো, একটি কনটেইনারের 
+নিজস্ব ফাইল সিস্টেম, CPU ভাগ, মেমরি, প্রক্রিয়া স্থান এবং আরও অনেক কিছু রয়েছে। যেহেতু এগুলি 
+অন্তর্নিহিত অবকাঠামো থেকে আলাদা করা হয়েছে, তারা ক্লাউড এবং 
+OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্য।
+
+কন্টেইনারগুলো জনপ্রিয় হয়ে উঠেছে কারণ তারা অতিরিক্ত সুবিধা প্রদান করে, যেমন:
+
+* এজাইল (Agile) অ্যাপ্লিকেশন তৈরি এবং ডিপ্লয়মেন্টয়: ভিএম ইমেজ (VM Image) ব্যবহারের তুলনায় কন্টেইনার ইমেজ (Container Image) 
+  তৈরির সহজতা এবং দক্ষতা বেশি। 
+* ক্রমাগত বিকাশ, একীকরণ এবং ডিপ্লয়মেন্ট: নির্ভরযোগ্য এবং ঘন ঘন
+  কন্টেইনার ইমেজ তৈরি এবং ডিপ্লয়মেন্টের জন্য প্রদান করে দ্রুত এবং
+  দক্ষ রোলব্যাকের (ইমেজ অপরিবর্তনীয়তার কারণে) সাথে ।
+* ডেভ (Dev) এবং অপস (Ops) উদ্বেগের বিচ্ছেদ: বিল্ড/রিলিজের সময়ে
+  অ্যাপ্লিকেশন কন্টেইনার ইমেজ তৈরি করে ডিপ্লয়মেন্টের সময়ের তুলনায়,
+  ফলস্বরূপ অ্যাপ্লিকেশনগুলি অবকাঠামো থেকে বিচ্ছিন্ন হয়। 
+* পর্যবেক্ষণযোগ্যতা: শুধুমাত্র OS-স্তরের তথ্য এবং মেট্রিক্সই নয়, 
+  প্রয়োগের স্বাস্থ্য এবং অন্যান্য সংকেতও।
+* ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন জুড়ে পরিবেশগত সামঞ্জস্য: একটি 
+  ল্যাপটপে ক্লাউডের মতোই চলে।
+* ক্লাউড এবং ওএস ডিস্ট্রিবিউশন পোর্টেবিলিটি: উবুন্টু (Ubuntu), রেল (RHEL), কোরওস (CoreOS), অন-প্রিমিসেস (on-premises), 
+  প্রধান পাবলিক ক্লাউডসর উপর, এবং অন্য কোথাও চলে।
+* অ্যাপ্লিকেশন-কেন্দ্রিক ব্যবস্থাপনা: ভার্চুয়াল হার্ডওয়্যারে একটি OS চালানো থেকে 
+  লজিক্যাল রিসোর্স ব্যবহার করে একটি OS-এ একটি অ্যাপ্লিকেশন চালানো পর্যন্ত বিমূর্ততার স্তর বাড়ায়।
+* ঢিলেঢালাভাবে সংযুক্ত, বিতরণ করা, স্থিতিস্থাপক, মুক্ত মাইক্রো-পরিষেবা: অ্যাপ্লিকেশনগুলিকে 
+  ছোট, স্বাধীন টুকরোগুলিতে বিভক্ত করা হয় এবং গতিশীলভাবে স্থাপন ও পরিচালনা করা যায় – 
+  একটি বড় একক-উদ্দেশ্য মেশিনে চলমান একটি মনোলিথিক স্ট্যাক নয়।.
+* রিসোর্স আইসোলেশন: অনুমানযোগ্য অ্যাপ্লিকেশন কর্মক্ষমতা।
+* রিসোর্স ব্যবহার: উচ্চ দক্ষতা এবং ঘনত্ব।
+
+
 ## {{% heading "whatsnext" %}}
 
 * [কুবারনেটিস উপাদান](/bn/docs/concepts/overview/components/) একবার দেখুন

content/bn/docs/concepts/overview/working-with-objects/_index.md

@@ -1,7 +1,7 @@
 ---
 title: কুবারনেটিসে অবজেক্ট
 content_type: concept
-weight: 10
+weight: 30
 description: >
    কুবারনেটিস অবজেক্ট হল কুবারনেটিস সিস্টেমে স্থায়ী সত্তা।
    কুবারনেটিস আপনার ক্লাস্টারের অবস্থার প্রতিনিধিত্ব করতে এই সত্তাগুলি ব্যবহার করে।
@@ -73,7 +73,7 @@ card:
 কিছু মৌলিক তথ্য (যেমন নাম) প্রদান করতে হবে। যখন আপনি অবজেক্ট তৈরি
 করতে কুবারনেটিস API ব্যবহার করেন (এটা সরাসরি বা `kubectl` এর মাধ্যমে), 
 তখন ঐ API অনুরোধটি এই তথ্যকে একটি JSON রিকোয়েস্ট বডি হিসেবে অন্তর্ভুক্ত করতে হবে। 
-সাধারণত, আপনি একটি manifest নামে পরিচিত ফাইলে kubectl কে তথ্য প্রদান করেন। নিয়ম অনুসারে, ম্যানিফেস্ট হল YAML (আপনি JSON 
+সাধারণত, আপনি একটি manifest নামে পরিচিত ফাইলে `kubectl` কে তথ্য প্রদান করেন। নিয়ম অনুসারে, ম্যানিফেস্ট হল YAML (আপনি JSON 
 ফরম্যাটও ব্যবহার করতে পারেন)। HTTP-এর মাধ্যমে API অনুরোধ করার সময় টুল যেমন kubectl একটি ম্যানিফেস্ট থেকে তথ্যকে JSON বা অন্য 
 সমর্থিত সিরিয়ালাইজেশন ফরম্যাটে রূপান্তর করে।
 
@@ -172,4 +172,4 @@ YAML কনফিগারেশন ফাইল লেখার অতিরি
 * [Kubernetes API overview](/bn/docs/reference/using-api/)
 
 কুবারনেটিসে অবজেক্টগুলির বিস্তারিত জানতে, এই বিভাগে অন্যান্য পৃষ্ঠাগুলি পড়ুন:
-<!-- Docsy automatically includes a list of pages in the section -->
+<!-- Docsy automatically includes a list of pages in the section -->

content/bn/docs/concepts/services-networking/_index.md

@@ -7,7 +7,8 @@ description: >
 
 ## কুবারনেটিস নেটওয়ার্ক মডেল
 
-একটি ক্লাস্টারের প্রতিটি [`পড`](/bn/docs/concepts/workloads/pods/) তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায়।
+একটি ক্লাস্টারের প্রতিটি [`পড`](/bn/docs/concepts/workloads/pods/) তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায় 
+(প্রতি আইপি এড্রেস ফ্যামিলিতে একটি আইপি এড্রেস)।
 এর অর্থ হলো আপনাকে `পডের` মধ্যে স্পষ্টভাবে লিঙ্ক তৈরি করার দরকার নেই 
 এবং পোর্টগুলো হোস্ট করার জন্য আপনাকে ম্যাপিং কন্টেইনার পোর্টগুলোর সাথে মোকাবিলা করতে হবে না।
 এটি একটি পরিষ্কার, পিছনের-সামঞ্জস্যপূর্ণ মডেল (backwards-compatible model) তৈরি করে 
@@ -23,9 +24,9 @@ description: >
    * একটি নোডের এজেন্ট (যেমন system daemons, kubelet) সেই নোডের সমস্ত
      পডের সাথে যোগাযোগ করতে পারে
 
-দ্রষ্টব্য: হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান `পডগুলোকে` সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য, 
+{{< note >}}
-যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও 
+হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান `পডগুলোকে` সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য, যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷
-তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷
+{{< /note >}}
 
 এই মডেলটি শুধুমাত্র সামগ্রিকভাবে কম জটিল নয়, 
 এটি প্রধানত কুবারনেটিসের ইচ্ছার সাথে সামঞ্জস্যপূর্ণ যাতে ভিএম থেকে কন্টেইনারে 

content/bn/docs/reference/glossary/container-runtime-interface.md

@@ -0,0 +1,22 @@
+---
+title: কন্টেইনার রানটাইম ইন্টারফেস (Container Runtime Interface)
+id: container-runtime-interface
+date: 2021-11-24
+full_link: /docs/concepts/architecture/cri
+short_description: >
+  kubelet এবং কন্টেইনার রানটাইমের মধ্যে যোগাযোগের জন্য প্রধান প্রোটোকল।
+
+aka:
+tags:
+  - cri
+---
+
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} এবং কন্টেইনার রানটাইমের এর মধ্যে যোগাযোগের জন্য প্রধান প্রোটোকল।
+
+<!--more-->
+
+কুবারনেটিস কন্টেইনার রানটাইম ইন্টারফেস (CRI)
+[নোড কম্পোনেন্ট](/docs/concepts/architecture/#node-components)
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} এবং
+{{< glossary_tooltip text="কন্টেইনার রানটাইমের" term_id="container-runtime" >}}
+মধ্যে যোগাযোগের জন্য প্রধান [gRPC](https://grpc.io) প্রোটোকলকে সংজ্ঞায়িত করে।

content/bn/docs/reference/glossary/kube-apiserver.md

@@ -2,7 +2,7 @@
 title: API সার্ভার
 id: kube-apiserver
 date: 2018-04-12
-full_link: /bn/docs/concepts/overview/components/#kube-apiserver
+full_link: /docs/concepts/architecture/#kube-apiserver
 short_description: >
    কন্ট্রোল প্লেন উপাদান যা কুবারনেটিস API পরিবেশন করে।
 

content/bn/docs/setup/production-environment/_index.md

@@ -45,11 +45,11 @@ no_list: true
   অ্যাডমিন সুবিধা রয়েছে। কিন্তু গুরুত্বপূর্ণ ওয়ার্কলোড সহ ভাগ করা ক্লাস্টার, এবং
   এক বা দুইজনের বেশি ব্যবহারকারীর জন্য কে এবং কি ক্লাস্টার রিসোর্স অ্যাক্সেস করতে পারে তার
   জন্য আরও পরিমার্জিত পদ্ধতির প্রয়োজন। আপনি রোল-বেসড অ্যাক্সেস কন্ট্রোল
-  ([RBAC](/bn/docs/reference/access-authn-authz/rbac/)) এবং অন্যান্য
+  ([RBAC](/docs/reference/access-authn-authz/rbac/)) এবং অন্যান্য
   নিরাপত্তা ব্যবস্থা ব্যবহার করতে পারেন যাতে ব্যবহারকারী এবং ওয়ার্কলোড তাদের প্রয়োজনীয়
   রিসোর্সগুলিতে অ্যাক্সেস পেতে পারে ওয়ার্কলোড, এবং ক্লাস্টার নিজেই নিরাপদ।
   [পলিসি](/bn/docs/concepts/policy/) এবং
-  [কন্টেইনার রিসোর্স](/bn/docs/concepts/configuration/manage-resources-containers/) পরিচালনার মাধ্যমে
+  [কন্টেইনার রিসোর্স](/docs/concepts/configuration/manage-resources-containers/) পরিচালনার মাধ্যমে
   ব্যবহারকারী এবং ওয়ার্কলোড যে রিসোর্সগুলি অ্যাক্সেস করতে পারে তার উপর আপনি সীমা নির্ধারণ করতে পারেন।
 
 কুবারনেটিস প্রোডাকশন এনভায়রনমেন্ট নিজে থেকে তৈরি করার আগে, এই
@@ -86,7 +86,7 @@ no_list: true
 
 সহজতম কুবারনেটিস ক্লাস্টারে একই মেশিনে পুরো কন্ট্রোল প্লেন এবং ওয়ার্কার
 নোড সার্ভিসগুলি চলে। আপনি ওয়ার্কার নোডগুলি যোগ করে সেই এনভায়রনমেন্ট
-বাড়াতে পারেন, যেমনটি [কুবারনেটিস কম্পোনেন্ট](/bn/docs/concepts/overview/components/) এ
+বাড়াতে পারেন, যেমনটি [কুবারনেটিস কম্পোনেন্ট](/docs/concepts/overview/components/) এ
 চিত্রিত চিত্রে প্রতিফলিত হয়েছে।
 যদি ক্লাস্টারটি অল্প সময়ের জন্য পাওয়া যায় বা কিছু গুরুতর ভুল হয়ে গেলে তা
 বাতিল করা যেতে পারে, তাহলে এটি আপনার প্রয়োজন মেটাতে পারে।
@@ -107,10 +107,10 @@ no_list: true
 - *সার্টিফিকেট পরিচালনা করুন*: কন্ট্রোল প্লেন সার্ভিসগুলির মধ্যে সুরক্ষিত যোগাযোগ সার্টিফিকেট
   ব্যবহার করে প্রয়োগ করা হয়। সার্টিফিকেটগুলি স্থাপনের সময় স্বয়ংক্রিয়ভাবে তৈরি হয় বা
   আপনি আপনার নিজের সার্টিফিকেট কর্তৃপক্ষ ব্যবহার করে সেগুলি তৈরি করতে পারেন৷
-  বিস্তারিত জানার জন্য [PKI সার্টিফিকেট এবং প্রয়োজনীয়তা](/bn/docs/setup/best-practices/certificates/) দেখুন।
+  বিস্তারিত জানার জন্য [PKI সার্টিফিকেট এবং প্রয়োজনীয়তা](/docs/setup/best-practices/certificates/) দেখুন।
 - *apiserver এর জন্য লোড ব্যালেন্সার কনফিগার করুন*: বিভিন্ন নোডে চলমান apiserver
   সার্ভিস দৃষ্টান্তগুলিতে বহিরাগত API অনুরোধগুলি বিতরণ করতে একটি লোড ব্যালেন্সার কনফিগার করুন। দেখুন
-  [একটি বাহ্যিক লোড ব্যালেন্সার তৈরি করুন](/bn/docs/tasks/access-application-cluster/create-external-load-balancer/)
+  [একটি বাহ্যিক লোড ব্যালেন্সার তৈরি করুন](/docs/tasks/access-application-cluster/create-external-load-balancer/)
   বিস্তারিত জানার জন্য.
 - *পৃথক এবং ব্যাকআপ etcd সার্ভিস*: etcd সার্ভিসগুলি হয় অন্যান্য কন্ট্রোল প্লেন
   সার্ভিসগুলির মতো একই মেশিনে চলতে পারে বা অতিরিক্ত নিরাপত্তা এবং প্রাপ্যতার জন্য
@@ -118,8 +118,8 @@ no_list: true
   তাই etcd ডাটাবেসের ব্যাকআপ নিয়মিত করা উচিত যাতে আপনি প্রয়োজনে
   সেই ডাটাবেসটি মেরামত করতে পারেন।
   etcd কনফিগার করা এবং ব্যবহার করার বিষয়ে বিস্তারিত জানার জন্য [etcd FAQ](https://etcd.io/docs/v3.5/faq/) দেখুন।
-  [কুবারনেটিস-এর জন্য অপারেটিং etcd ক্লাস্টার](/bn/docs/tasks/administer-cluster/configure-upgrade-etcd/)
+  [কুবারনেটিস-এর জন্য অপারেটিং etcd ক্লাস্টার](/docs/tasks/administer-cluster/configure-upgrade-etcd/)
-  দেখুন এবং [kubeadm-এর সাথে একটি উচ্চ প্রাপ্যতা etcd ক্লাস্টার সেট আপ করুন](/bn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
+  দেখুন এবং [kubeadm-এর সাথে একটি উচ্চ প্রাপ্যতা etcd ক্লাস্টার সেট আপ করুন](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
   বিস্তারিত জানার জন্য।
 - *মাল্টিপল কন্ট্রোল প্লেন সিস্টেম তৈরি করুন*: উচ্চ প্রাপ্যতা জন্য,
   কন্ট্রোল প্লেন একটি একক মেশিনে সীমাবদ্ধ করা উচিত নয়। যদি কন্ট্রোল প্লেন
@@ -137,25 +137,25 @@ no_list: true
   একই রিজিওনে মাল্টিপল জোনে
   একটি ক্লাস্টার ছড়িয়ে দেওয়ার মাধ্যমে, এটি একটি জোন অপ্রাপ্য হয়ে গেলেও
   আপনার ক্লাস্টারটি কাজ করা চালিয়ে যাওয়ার সম্ভাবনাকে উন্নত করতে পারে।
-  বিস্তারিত জানার জন্য [মাল্টিপল জোনে চলমান](/bn/docs/setup/best-practices/multiple-zones/) দেখুন।
+  বিস্তারিত জানার জন্য [মাল্টিপল জোনে চলমান](/docs/setup/best-practices/multiple-zones/) দেখুন।
 - *চলমান ফিচারগুলি পরিচালনা করুন*: আপনি যদি সময়ের সাথে সাথে আপনার ক্লাস্টার রাখার পরিকল্পনা করেন
   তবে এর স্বাস্থ্য এবং নিরাপত্তা বজায় রাখার জন্য আপনাকে কিছু কাজ করতে হবে। উদাহরণস্বরূপ,
   আপনি যদি kubeadm-এর সাথে ইনস্টল করেন, তাহলে আপনাকে
-  [সার্টিফিকেট ম্যানেজমেন্ট](/bn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)
+  [সার্টিফিকেট ম্যানেজমেন্ট](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)
-  এবং [kubeadm ক্লাস্টার আপগ্রেড করা](/bn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) সাহায্য করার জন্য নির্দেশাবলী রয়েছে।
+  এবং [kubeadm ক্লাস্টার আপগ্রেড করা](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) সাহায্য করার জন্য নির্দেশাবলী রয়েছে।
   কুবারনেটিস অ্যাডমিনিস্ট্রেটিভ কাজগুলির একটি দীর্ঘ তালিকার জন্য
-  [একটি ক্লাস্টার পরিচালনা](/bn/docs/tasks/administer-cluster/) দেখুন।
+  [একটি ক্লাস্টার পরিচালনা](/docs/tasks/administer-cluster/) দেখুন।
 
 আপনি যখন কন্ট্রোল প্লেন সার্ভিসগুলি চালান তখন এভেইল্যাবল বিকল্পগুলি সম্পর্কে জানতে,
-[kube-apiserver](/bn/docs/reference/command-line-tools-reference/kube-apiserver/),
+[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
-[kube-controller-manager](/bn/docs/reference/command-line-tools-reference/kube-controller-manager/) দেখুন,
+[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) দেখুন,
-এবং [kube-scheduler](/bn/docs/reference/command-line-tools-reference/kube-scheduler/)
+এবং [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
 কম্পোনেন্ট পৃষ্ঠা। হাইলি এভেইল্যাবল কন্ট্রোল প্লেন উদাহরণের জন্য,
-[হাইলি এভেইল্যাবল টপোলজির বিকল্পগুলি](/bn/docs/setup/production-environment/tools/kubeadm/ha-topology/),
+[হাইলি এভেইল্যাবল টপোলজির বিকল্পগুলি](/docs/setup/production-environment/tools/kubeadm/ha-topology/),
-[kubeadm-এর সাহায্যে হাইলি এভেইল্যাবল ক্লাস্টার তৈরি করা](/bn/docs/setup/production-environment/tools/kubeadm/high-availability/) দেখুন,
+[kubeadm-এর সাহায্যে হাইলি এভেইল্যাবল ক্লাস্টার তৈরি করা](/docs/setup/production-environment/tools/kubeadm/high-availability/) দেখুন,
-এবং [অপারেটিং etcd ক্লাস্টার-এর জন্য কুবারনেটিস](/bn/docs/tasks/administer-cluster/configure-upgrade-etcd/)।
+এবং [অপারেটিং etcd ক্লাস্টার-এর জন্য কুবারনেটিস](/docs/tasks/administer-cluster/configure-upgrade-etcd/)।
 একটি etcd ব্যাকআপ প্ল্যান তৈরির তথ্যের জন্য
-[একটি etcd ক্লাস্টার ব্যাক আপ করা](/bn/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) দেখুন।
+[একটি etcd ক্লাস্টার ব্যাক আপ করা](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) দেখুন।
 
 ### প্রোডাকশন ওয়ার্কার নোড
 
@@ -167,13 +167,13 @@ no_list: true
 
 - *নোডগুলি কনফিগার করুন*: নোডগুলি ফিজিক্যাল বা ভার্চুয়াল মেশিন হতে পারে। আপনি যদি
   নিজের নোডগুলি তৈরি করতে এবং পরিচালনা করতে চান তবে আপনি একটি সমর্থিত অপারেটিং সিস্টেম ইনস্টল করতে পারেন,
-  তারপরে উপযুক্ত [নোড সার্ভিসগুলি](/bn/docs/concepts/overview/components/#node-components)
+  তারপরে উপযুক্ত [নোড সার্ভিসগুলি](/docs/concepts/architecture/#node-components)
   যোগ করুন এবং চালান। বিবেচনা করুন:
   - উপযুক্ত মেমরি, সিপি উ, এবং ডিস্কের গতি এবং স্টোরেজ ক্ষমতা এভেইল্যাবল থাকার মাধ্যমে আপনি যখন নোড সেট আপ করেন তখন আপনার ওয়ার্কলোডের চাহিদা।
   - জেনেরিক কম্পিউটার সিস্টেমগুলি করবে কিনা বা আপনার কাছে এমন ওয়ার্কলোড আছে যেগুলির জন্য জিপিউ প্রসেসর, উইন্ডোজ নোড, বা ভিএম আইসোলেশন প্রয়োজন।
 - *ভ্যালিডেট নোড*: কিভাবে একটি নোড একটি কুবারনেটিস ক্লাস্টারে
   যোগদানের প্রয়োজনীয়তা পূরণ করে তা নিশ্চিত করার তথ্যের জন্য
-  [ভ্যালিড নোড সেটআপ](/bn/docs/setup/best-practices/node-conformance/) দেখুন।
+  [ভ্যালিড নোড সেটআপ](/docs/setup/best-practices/node-conformance/) দেখুন।
 - *ক্লাস্টারে নোড যোগ করুন*: আপনি যদি নিজের ক্লাস্টার পরিচালনা করেন তাহলে আপনি
   আপনার নিজস্ব মেশিন সেট আপ করে নোড যোগ করতে পারেন এবং হয় সেগুলিকে ম্যানুয়ালি যোগ করে অথবা
   ক্লাস্টারের apiserver এ নিজেদের নিবন্ধন করতে পারেন। এই উপায়ে
@@ -181,14 +181,14 @@ no_list: true
 - *নোড স্কেল করুন*: আপনার ক্লাস্টারের শেষ পর্যন্ত যে ক্ষমতা প্রয়োজন তা প্রসারিত করার জন্য একটি
   পরিকল্পনা করুন। আপনার চালানোর জন্য কতগুলি পড এবং কন্টেইনার প্রয়োজন
   তার উপর ভিত্তি করে আপনার কতগুলি নোড প্রয়োজন তা নির্ধারণ করতে সাহায্য করতে
-  [বড় ক্লাস্টারগুলির জন্য বিবেচনা](/bn/docs/setup/best-practices/cluster-large/) দেখুন। আপনি যদি নিজে নোড পরিচালনা করেন, তাহলে এর অর্থ
+  [বড় ক্লাস্টারগুলির জন্য বিবেচনা](/docs/setup/best-practices/cluster-large/) দেখুন। আপনি যদি নিজে নোড পরিচালনা করেন, তাহলে এর অর্থ
   হতে পারে আপনার নিজের ফিজিক্যাল টুল কেনা এবং ইনস্টল করা।
 - *নোড অটোস্কেল করুন*: আপনার নোডগুলি স্বয়ংক্রিয়ভাবে পরিচালনা করার জন্য উপলব্ধ সরঞ্জামগুলি এবং
   তাদের সরবরাহ করা ক্ষমতা সম্পর্কে জানতে
-  [Cluster Autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling) পড়ুন।
+  [ক্লাস্টার অটোস্কেলিং](/docs/concepts/cluster-administration/cluster-autoscaling) পড়ুন।
 - *নোড স্বাস্থ্য পরীক্ষা সেট আপ করুন*: গুরুত্বপূর্ণ ওয়ার্কলোডের জন্য, আপনি নিশ্চিত করতে চান যে
   সেই নোডগুলিতে চলমান নোড এবং পডগুলি স্বাস্থ্যকর।
-  [নোড প্রবলেম ডিটেক্টর](/bn/docs/tasks/debug-application-cluster/monitor-node-health/)
+  [নোড প্রবলেম ডিটেক্টর](/docs/tasks/debug-application-cluster/monitor-node-health/)
   daemon ব্যবহার করে, আপনি নিশ্চিত করতে পারেন আপনার নোডগুলি সুস্থ।
 
 ## প্রোডাকশন ব্যবহারকারী ব্যবস্থাপনা
@@ -210,45 +210,45 @@ no_list: true
   আপনি কোন অথেনটিকেশন পদ্ধতি ব্যবহার করতে চান তা নির্বাচন করতে পারেন।
   প্লাগইন ব্যবহার করে, apiserver আপনার প্রতিষ্ঠানের বিদ্যমান সুবিধা নিতে পারে
   অথেনটিকেশন পদ্ধতি, যেমন LDAP বা Kerberos। দেখা
-  [অথেনটিকেশন](/bn/docs/reference/access-authn-authz/authentication/)
+  [অথেনটিকেশন](/docs/reference/access-authn-authz/authentication/)
   কুবারনেটিস ব্যবহারকারীদের অথেনটিকেশনের এই বিভিন্ন পদ্ধতির বর্ণনার জন্য।
 - *অথোরাইজেশন*: আপনি যখন আপনার নিয়মিত ব্যবহারকারীদের অথোরাইজেশন করার জন্য প্রস্তুত হন, আপনি সম্ভবত
   RBAC এবং ABAC অথোরাইজেশনের মধ্যে বেছে নেবেন। ব্যবহারকারীর অ্যাকাউন্ট অথোরাইজেশনের জন্য বিভিন্ন মোড পর্যালোচনা করতে
-  [অথোরাইজেশন  ওভারভিউ](/bn/docs/reference/access-authn-authz/authorization/) দেখুন (সেইসাথে আপনার ক্লাস্টারে সার্ভিস
+  [অথোরাইজেশন  ওভারভিউ](/docs/reference/access-authn-authz/authorization/) দেখুন (সেইসাথে আপনার ক্লাস্টারে সার্ভিস
   অ্যাকাউন্ট অ্যাক্সেস):
-  - *রোল-বেসড অ্যাক্সেস কন্ট্রোল* ([RBAC](/bn/docs/reference/access-authn-authz/rbac/)):
+  - *রোল-বেসড অ্যাক্সেস কন্ট্রোল* ([RBAC](/docs/reference/access-authn-authz/rbac/)):
     অথেন্টিকেটেড ব্যবহারকারীদের নির্দিষ্ট সেটের অনুমতি প্রদান করে আপনাকে আপনার ক্লাস্টারে অ্যাক্সেস বরাদ্দ করতে দেয়।
     একটি নির্দিষ্ট নেমস্পেস (Role) বা সমগ্র ক্লাস্টার জুড়ে (ClusterRole) অনুমতিগুলি বরাদ্দ
     করা যেতে পারে। তারপর RoleBindings এবং ClusterRoleBindings ব্যবহার করে, সেই অনুমতিগুলি নির্দিষ্ট ব্যবহারকারীদের সাথে
     সংযুক্ত করা যেতে পারে।
-  - *অ্যাট্রিবিউট-বেসড অ্যাক্সেস কন্ট্রোল* ([ABAC](/bn/docs/reference/access-authn-authz/abac/)):
+  - *অ্যাট্রিবিউট-বেসড অ্যাক্সেস কন্ট্রোল* ([ABAC](/docs/reference/access-authn-authz/abac/)):
     আপনাকে ক্লাস্টারে রিসোর্স অ্যাট্রিবিউটের উপর ভিত্তি করে পলিসি তৈরি করতে দেয় এবং সেই অ্যাট্রিবিউটগুলির উপর ভিত্তি করে অ্যাক্সেসের
     অনুমতি দেয় বা অস্বীকার করে। একটি পলিসি ফাইলের প্রতিটি লাইন ভার্শনিং বৈশিষ্ট্য (apiVersion
     এবং kind) এবং বিষয় (ব্যবহারকারী বা গ্রুপ), রিসোর্স বৈশিষ্ট্য,
     নন-রিসোর্সে বৈশিষ্ট্য (/version বা /apis) এবং শুধুমাত্র পঠনযোগ্য বৈশিষ্ট্যের সাথে মেলে বিশেষ বৈশিষ্ট্যগুলির একটি মানচিত্র সনাক্ত করে।
-    বিস্তারিত জানার জন্য [উদাহরণ](/bn/docs/reference/access-authn-authz/abac/#examples) দেখুন.
+    বিস্তারিত জানার জন্য [উদাহরণ](/docs/reference/access-authn-authz/abac/#examples) দেখুন.
 
 যেহেতু কেউ আপনার প্রোডাকশন কুবারনেটস ক্লাস্টারে অথেনটিকেশন এবং অথোরাইজেশন সেট আপ করছে, এখানে কিছু বিষয় বিবেচনা করার আছেঃ
 
 - *অথোরাইজেশন মোড সেট করুন*: যখন Kubernetes API সার্ভার
-  ([kube-apiserver](/bn/docs/reference/command-line-tools-reference/kube-apiserver/)) শুরু হয়,
+  ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) শুরু হয়,
   তখন সমর্থিত অথেনটিকেশন মোডগুলি *--authorization-mode* ফ্ল্যাগ ব্যবহার করে সেট করতে হবে।
   উদাহরণস্বরূপ, *kube-adminserver.yaml* ফাইলে (*/etc/kubernetes/manifests*-এ) সেই ফ্ল্যাগটি
   Node,RBAC-তে সেট করা যেতে পারে। এটি অথেন্টিকেটেড অনুরোধের জন্য নোড এবং RBAC অথোরাইজেশনের অনুমতি দেবে।
 - *ব্যবহারকারী সার্টিফিকেট এবং রোল বাইন্ডিং (RBAC)ভর্তি নিয়ন্ত্রক বিবেচনা করুন*: আপনি যদি RBAC অথোরাইজেশন ব্যবহার করেন,
   ব্যবহারকারীরা একটি CertificateSigningRequest (CSR) তৈরি করতে পারে যা ক্লাস্টার
   CA দ্বারা স্বাক্ষরিত হতে পারে। তারপর আপনি প্রতিটি ব্যবহারকারীর রোল এবং ক্লাস্টার রোল বাইন্ড করতে পারেন।
-  বিস্তারিত জানার জন্য [সার্টিফিকেট স্বাক্ষরের অনুরোধ](/bn/docs/reference/access-authn-authz/certificate-signing-requests/)
+  বিস্তারিত জানার জন্য [সার্টিফিকেট স্বাক্ষরের অনুরোধ](/docs/reference/access-authn-authz/certificate-signing-requests/)
   দেখুন।
 - *অ্যাট্রিবিউটগুলিকে একত্রিত করে এমন পলিসি তৈরি করুন (ABAC)*: আপনি যদি ABAC অথোরাইজেশন ব্যবহার করেন,
   আপনি নির্দিষ্ট রিসোর্সগুলি (যেমন একটি পড), নেমস্পেস, বা apiGroup অ্যাক্সেস করার জন্য নির্বাচিত
   ব্যবহারকারী বা গ্রুপগুলিকে অথোরাইজেশন করার জন্য পলিসিগুলি গঠনের জন্য অ্যাট্রিবিউটগুলিকে সংমিশ্রণ
   বরাদ্দ করতে পারেন। আরও তথ্যের জন্য,
-  [উদাহরণ](/bn/docs/reference/access-authn-authz/abac/#examples) দেখুন।
+  [উদাহরণ](/docs/reference/access-authn-authz/abac/#examples) দেখুন।
 - *অ্যাডমিশন কন্ট্রোলারদের বিবেচনা করুন*: API সার্ভারের মাধ্যমে যে অনুরোধগুলি
   আসতে পারে তার অথোরাইজেশনের অতিরিক্ত ফর্মগুলির মধ্যে রয়েছে
-  [ওয়েবহুক টোকেন অথেনটিকেশন](/bn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)।
+  [ওয়েবহুক টোকেন অথেনটিকেশন](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)।
-  API সার্ভারে [অ্যাডমিশন কন্ট্রোলার](/bn/docs/reference/access-authn-authz/admission-controllers/)
+  API সার্ভারে [অ্যাডমিশন কন্ট্রোলার](/docs/reference/access-authn-authz/admission-controllers/)
   যোগ করে ওয়েবহুক এবং অন্যান্য বিশেষ অথোরাইজেশনের ধরন
   সক্ষম করতে হবে।
 
@@ -259,23 +259,23 @@ no_list: true
 এই আইটেমগুলি বিবেচনা করুনঃ
 
 - *নেমস্পেস সীমা সেট করুন*: মেমরি এবং সিপিইউ এর মত জিনিসগুলিতে প্রতি-নেমস্পেস কোটা সেট করুন। বিস্তারিত
-  জানার জন্য [Manage Memory, CPU, and API Resources](/bn/docs/tasks/administer-cluster/manage-resources/)
+  জানার জন্য [Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/)
   দেখুন। এছাড়াও আপনি উত্তরাধিকার
   সীমার জন্য [হায়ারার্কিক্যাল নেমস্পেস](/blog/2020/08/14/introducing-hierarchical-namespaces/)
   সেট করতে পারেন।
 - *ডিএনএস চাহিদার জন্য প্রস্তুত করুন*: আপনি যদি আশা করেন যে ওয়ার্কলোড ব্যাপকভাবে বৃদ্ধি পাবে,
   আপনার DNS সার্ভিসটিও স্কেল বাড়াতে প্রস্তুত থাকতে হবে। দেখুন
-  [একটি ক্লাস্টারে DNS সার্ভিসটি অটোস্কেল করুন](/bn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)।
+  [একটি ক্লাস্টারে DNS সার্ভিসটি অটোস্কেল করুন](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)।
 - *অতিরিক্ত সার্ভিস অ্যাকাউন্ট তৈরি করুন*: ব্যবহারকারীর অ্যাকাউন্টগুলি নির্ধারণ করে যে ব্যবহারকারীরা
   একটি ক্লাস্টারে কী করতে পারে, যখন একটি সার্ভিস অ্যাকাউন্ট একটি নির্দিষ্ট নেমস্পেসের মধ্যে পড
   অ্যাক্সেসকে সংজ্ঞায়িত করে। ডিফল্টরূপে, একটি পড তার নেমস্পেস থেকে ডিফল্ট সার্ভিস অ্যাকাউন্টে নেয়।
-  একটি নতুন সার্ভিস অ্যাকাউন্ট তৈরি করার তথ্যের জন্য [সার্ভিস অ্যাকাউন্ট পরিচালনা করা](/bn/docs/reference/access-authn-authz/service-accounts-admin/)
+  একটি নতুন সার্ভিস অ্যাকাউন্ট তৈরি করার তথ্যের জন্য [সার্ভিস অ্যাকাউন্ট পরিচালনা করা](/docs/reference/access-authn-authz/service-accounts-admin/)
   দেখুন। উদাহরণস্বরূপ, আপনি চাইতে পারেন:
   - সিক্রেট যোগ করুন যা একটি পড একটি নির্দিষ্ট কন্টেইনার রেজিস্ট্রি থেকে ইমেজ পুল করতে ব্যবহার করতে পারে।
-    উদাহরণের জন্য [পডের জন্য সার্ভিস অ্যাকাউন্ট কনফিগার করুন](/bn/docs/tasks/configure-pod-container/configure-service-account/)
+    উদাহরণের জন্য [পডের জন্য সার্ভিস অ্যাকাউন্ট কনফিগার করুন](/docs/tasks/configure-pod-container/configure-service-account/)
     দেখুন।
   - একটি সার্ভিস অ্যাকাউন্টে RBAC অনুমতিগুলি বরাদ্দ করুন৷ বিস্তারিত জানার জন্য
-    [সার্ভিস অ্যাকাউন্ট অনুমতি](/bn/docs/reference/access-authn-authz/rbac/#service-account-permissions)
+    [সার্ভিস অ্যাকাউন্ট অনুমতি](/docs/reference/access-authn-authz/rbac/#service-account-permissions)
     দেখুন।
 
 ## {{% heading "whatsnext" %}}
@@ -285,17 +285,17 @@ no_list: true
   অথবা [কুবারনেটিস অংশীদার](/bn/partners/) থেকে একটি পেতে চান।
 - আপনি যদি নিজের ক্লাস্টার তৈরি করতে চান,
   তাহলে পরিকল্পনা করুন আপনি কীভাবে
-  [সার্টিফিকেট](/bn/docs/setup/best-practices/certificates/) পরিচালনা করতে চান এবং
+  [সার্টিফিকেট](/docs/setup/best-practices/certificates/) পরিচালনা করতে চান এবং
-  [etcd](/bn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
+  [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
   এর মতো ফিচারগুলির জন্য উচ্চ প্রাপ্যতা সেট আপ করুন)
-  এবং [API সার্ভার](/bn/docs/setup/production-environment/tools/kubeadm/ha-topology/)।
+  এবং [API সার্ভার](/docs/setup/production-environment/tools/kubeadm/ha-topology/)।
 - [kubeadm](/bn/docs/setup/production-environment/tools/kubeadm/) থেকে ডিপ্লয়মেন্ট পদ্ধতি বেছে নিন,
   [kops](https://kops.sigs.k8s.io/) অথবা
   [Kubespray](https://kubespray.io/)।
-- আপনার [অথেনটিকেশন](/bn/docs/reference/access-authn-authz/authentication/)
+- আপনার [অথেনটিকেশন](/docs/reference/access-authn-authz/authentication/)
-  এবং [অথোরাইজেশন](/bn/docs/reference/access-authn-authz/authorization/)
+  এবং [অথোরাইজেশন](/docs/reference/access-authn-authz/authorization/)
   পদ্ধতি নির্ধারণ করে ব্যবহারকারী ব্যবস্থাপনা কনফিগার করুন।
-- [রিসোর্স লিমিট](/bn/docs/tasks/administer-cluster/manage-resources/),
+- [রিসোর্স লিমিট](/docs/tasks/administer-cluster/manage-resources/),
-  [DNS autoscaling](/bn/docs/tasks/administer-cluster/dns-horizontal-autoscaling)
+  [DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling)
   সেট আপ করে অ্যাপ্লিকেশন ওয়ার্কলোডের জন্য প্রস্তুত করুন /) এবং
-  [সার্ভিস অ্যাকাউন্ট](/bn/docs/reference/access-authn-authz/service-accounts-admin/)।
+  [সার্ভিস অ্যাকাউন্ট](/docs/reference/access-authn-authz/service-accounts-admin/)।

content/bn/examples/admin/dns/dnsutils.yaml

@@ -6,9 +6,6 @@ metadata:
 spec:
   containers:
   - name: dnsutils
-    image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3
+    image: registry.k8s.io/e2e-test-images/agnhost:2.39
-    command:
-      - sleep
-      - "infinity"
     imagePullPolicy: IfNotPresent
   restartPolicy: Always

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

@@ -51,7 +51,7 @@ Automatisierung die Informationen aus den `OWNERS`-Dateien.
 ### OWNERS Dateien und Front-Matter
 
 Das Kubernetes-Projekt verwendet ein Automatisierungstool namens prow für die Automatisierung im Zusammenhang mit GitHub-Issues und Pull-Requests. 
-Das [Kubernetes-Website-Repository](https://github.com/kubernetes/website) verwendet zwei [prow-Plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins):
+Das [Kubernetes-Website-Repository](https://github.com/kubernetes/website) verwendet zwei [prow-Plugins](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins):
 
 - blunderbuss
 - approve

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

@@ -51,7 +51,7 @@ generally using their own Kubernetes distributions and therefore they don't use
 packages provided by the Kubernetes project; more importantly, if someone else is
 managing Kubernetes for you, then they would usually take responsibility for that check.
 
-If you have a managed [control plane](/docs/concepts/overview/components/#control-plane-components)
+If you have a managed [control plane](/docs/concepts/architecture/#control-plane-components)
 but you are responsible for **managing the nodes yourself**, and any of those nodes run Linux,
 you should [check](#check-if-affected) whether you are affected.
 

content/en/blog/_posts/2023-09-26-happy-7th-birthday-kubeadm.md

@@ -31,7 +31,7 @@ To keep kubeadm lean, focused, and vendor/infrastructure agnostic, the following
 Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the
 [Cluster API](https://cluster-api.sigs.k8s.io/). Instead, kubeadm covers only the common denominator
 in every Kubernetes cluster: the
-[control plane](/docs/concepts/overview/components/#control-plane-components).
+[control plane](/docs/concepts/architecture/#control-plane-components).
 The user may install their preferred networking solution and other add-ons on top of Kubernetes
 *after* cluster creation.
 

content/en/blog/_posts/2023-11-07-introducing-sig-etcd.md

@@ -16,7 +16,7 @@ Special Interest Groups (SIGs) are a fundamental part of the Kubernetes project,
 
 ## The critical role of etcd
 
-If we look inside the control plane of a Kubernetes cluster, we will find [etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd), a consistent and highly-available key value store used as Kubernetes' backing store for all cluster data -- this description alone highlights the critical role that etcd plays, and the importance of it within the Kubernetes ecosystem.
+If we look inside the control plane of a Kubernetes cluster, we will find [etcd](https://kubernetes.io/docs/concepts/architecture/#etcd), a consistent and highly-available key value store used as Kubernetes' backing store for all cluster data -- this description alone highlights the critical role that etcd plays, and the importance of it within the Kubernetes ecosystem.
 
 This critical role makes the health of the etcd project and community an important consideration, and [concerns about the state of the project](https://groups.google.com/a/kubernetes.io/g/steering/c/e-O-tVSCJOk/m/N9IkiWLEAgAJ) in early 2022 did not go unnoticed. The changes in the maintainer team, amongst other factors, contributed to a situation that needed to be addressed.
 

content/en/blog/_posts/2024-05-21-sig-node-spotlight/index.md

@@ -62,7 +62,7 @@ with cheap hardware to large AI/ML-optimized GPU-enabled nodes. Nodes may stay o
 maybe be short-lived and be preempted at any moment as they are running on excess compute of a cloud
 provider.
 
-[`kubelet`](/docs/concepts/overview/components/#kubelet) — the
+[`kubelet`](/docs/concepts/architecture/#kubelet) — the
 Kubernetes agent on a node — must work in all these environments reliably. As for the performance
 of kubelet operations, this is becoming increasingly important today. On one hand, as Kubernetes is
 being used on extra small nodes more and more often in telecom and retail environments, it needs to

content/en/blog/_posts/2024-08-15-volume-attributes-class.md

@@ -0,0 +1,100 @@
+---
+layout: blog
+title: "Kubernetes 1.31: VolumeAttributesClass for Volume Modification Beta"
+date: 2024-08-15
+slug: kubernetes-1-31-volume-attributes-class
+author: >
+  Sunny Song (Google)
+  Matthew Cary (Google)
+---
+
+Volumes in Kubernetes have been described by two attributes: their storage class, and
+their capacity. The storage class is an immutable property of the volume, while the
+capacity can be changed dynamically with [volume
+resize](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims).
+
+This complicates vertical scaling of workloads with volumes. While cloud providers and
+storage vendors often offer volumes which allow specifying IO quality of service
+(Performance) parameters like IOPS or throughput and tuning them as workloads operate,
+Kubernetes has no API which allows changing them.
+
+We are pleased to announce that the [VolumeAttributesClass
+KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/3751-volume-attributes-class/README.md),
+alpha since Kubernetes 1.29, will be beta in 1.31. This provides a generic,
+Kubernetes-native API for modifying volume parameters like provisioned IO.
+
+Like all new volume features in Kubernetes, this API is implemented via the [container
+storage interface (CSI)](https://kubernetes-csi.github.io/docs/). In addition to the
+VolumeAttributesClass feature gate, your provisioner-specific CSI driver must support the
+new ModifyVolume API which is the CSI side of this feature.
+
+See the [full
+documentation](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/)
+for all details. Here we show the common workflow.
+
+### Dynamically modifying volume attributes.
+
+A `VolumeAttributesClass` is a cluster-scoped resource that specifies provisioner-specific
+attributes. These are created by the cluster administrator in the same way as storage
+classes. For example, a series of gold, silver and bronze volume attribute classes can be
+created for volumes with greater or lessor amounts of provisioned IO.
+
+```yaml
+apiVersion: storage.k8s.io/v1alpha1
+kind: VolumeAttributesClass
+metadata:
+  name: silver
+driverName: your-csi-driver
+parameters:
+  provisioned-iops: "500"
+  provisioned-throughput: "50MiB/s"
+---
+apiVersion: storage.k8s.io/v1alpha1
+kind: VolumeAttributesClass
+metadata:
+  name: gold
+driverName: your-csi-driver
+parameters:
+  provisioned-iops: "10000"
+  provisioned-throughput: "500MiB/s"
+```
+  
+An attribute class is added to a PVC in much the same way as a storage class.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: test-pv-claim
+spec:
+  storageClassName: any-storage-class
+  volumeAttributesClassName: silver
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 64Gi
+```
+
+Unlike a storage class, the volume attributes class can be changed:
+
+```
+kubectl patch pvc test-pv-claim -p '{"spec": "volumeAttributesClassName": "gold"}'
+```
+
+Kubernetes will work with the CSI driver to update the attributes of the
+volume. The status of the PVC will track the current and desired attributes
+class. The PV resource will also be updated with the new volume attributes class
+which will be set to the currently active attributes of the PV.
+
+### Limitations with the beta
+
+As a beta feature, there are still some features which are planned for GA but not yet
+present. The largest is quota support, see the
+[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/3751-volume-attributes-class/README.md)
+and discussion in
+[sig-storage](https://github.com/kubernetes/community/tree/master/sig-storage) for details.
+
+See the [Kubernetes CSI driver
+list](https://kubernetes-csi.github.io/docs/drivers.html) for up-to-date
+information of support for this feature in CSI drivers.

content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md

@@ -7,25 +7,25 @@ author: >
   Kensei Nakada (Tetrate)
 ---
 
-Kubernetes 1.29 introduced new fields `MatchLabelKeys` and `MismatchLabelKeys` in PodAffinity and PodAntiAffinity.
+Kubernetes 1.29 introduced new fields `matchLabelKeys` and `mismatchLabelKeys` in `podAffinity` and `podAntiAffinity`.
 
 In Kubernetes 1.31, this feature moves to beta and the corresponding feature gate (`MatchLabelKeysInPodAffinity`) gets enabled by default.
 
-## `MatchLabelKeys` - Enhanced scheduling for versatile rolling updates
+## `matchLabelKeys` - Enhanced scheduling for versatile rolling updates
 
-During a workload's (e.g., Deployment) rolling update, a cluster may have Pods from multiple versions at the same time. 
+During a workload's (e.g., Deployment) rolling update, a cluster may have Pods from multiple versions at the same time.
-However, the scheduler cannot distinguish between old and new versions based on the `LabelSelector` specified in PodAffinity or PodAntiAffinity. As a result, it will co-locate or disperse Pods regardless of their versions.
+However, the scheduler cannot distinguish between old and new versions based on the `labelSelector` specified in `podAffinity` or `podAntiAffinity`. As a result, it will co-locate or disperse Pods regardless of their versions.
 
 This can lead to sub-optimal scheduling outcome, for example:
-- New version Pods are co-located with old version Pods (PodAffinity), which will eventually be removed after rolling updates.
+- New version Pods are co-located with old version Pods (`podAffinity`), which will eventually be removed after rolling updates.
-- Old version Pods are distributed across all available topologies, preventing new version Pods from finding nodes due to PodAntiAffinity.
+- Old version Pods are distributed across all available topologies, preventing new version Pods from finding nodes due to `podAntiAffinity`.
 
-`MatchLabelKeys` is a set of Pod label keys and addresses this problem.
+`matchLabelKeys` is a set of Pod label keys and addresses this problem.
-The scheduler looks up the values of these keys from the new Pod's labels and combines them with `LabelSelector`
+The scheduler looks up the values of these keys from the new Pod's labels and combines them with `labelSelector`
-so that PodAffinity matches Pods that have the same key-value in labels.
+so that podAffinity matches Pods that have the same key-value in labels.
 
-By using label [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label) in `MatchLabelKeys`, 
+By using label [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label) in `matchLabelKeys`,
-you can ensure that only Pods of the same version are evaluated for PodAffinity or PodAntiAffinity.
+you can ensure that only Pods of the same version are evaluated for `podAffinity` or `podAntiAffinity`.
 
 ```yaml
 apiVersion: apps/v1
@@ -43,11 +43,11 @@ metadata:
             values:
             - database
         topologyKey: topology.kubernetes.io/zone
-        matchLabelKeys: 
+        matchLabelKeys:
         - pod-template-hash
 ```
 
-The above matchLabelKeys will be translated in Pods like:
+The above `matchLabelKeys` will be translated in Pods like:
 
 ```yaml
 kind: Pod
@@ -68,26 +68,26 @@ metadata:
           - key: pod-template-hash # Added from matchLabelKeys; Only Pods from the same replicaset will match this affinity.
             operator: In
             values:
-            - xyz 
+            - xyz
         topologyKey: topology.kubernetes.io/zone
-        matchLabelKeys: 
+        matchLabelKeys:
         - pod-template-hash
 ```
 
-## `MismatchLabelKeys` - Service isolation
+## `mismatchLabelKeys` - Service isolation
 
-`MismatchLabelKeys` is a set of Pod label keys, like `MatchLabelKeys`,
+`mismatchLabelKeys` is a set of Pod label keys, like `matchLabelKeys`,
-which looks up the values of these keys from the new Pod's labels, and merge them with `LabelSelector` as `key notin (value)`
+which looks up the values of these keys from the new Pod's labels, and merge them with `labelSelector` as `key notin (value)`
-so that PodAffinity does _not_ match Pods that have the same key-value in labels.
+so that `podAffinity` does _not_ match Pods that have the same key-value in labels.
 
-Suppose all Pods for each tenant get `tenant` label via a controller or a manifest management tool like Helm. 
+Suppose all Pods for each tenant get `tenant` label via a controller or a manifest management tool like Helm.
 
-Although the value of `tenant` label is unknown when composing each workload's manifest, 
+Although the value of `tenant` label is unknown when composing each workload's manifest,
 the cluster admin wants to achieve exclusive 1:1 tenant to domain placement for a tenant isolation.
 
-`MismatchLabelKeys` works for this usecase;
+`mismatchLabelKeys` works for this usecase;
-By applying the following affinity globally using a mutating webhook, 
+By applying the following affinity globally using a mutating webhook,
-the cluster admin can ensure that the Pods from the same tenant will land on the same domain exclusively, 
+the cluster admin can ensure that the Pods from the same tenant will land on the same domain exclusively,
 meaning Pods from other tenants won't land on the same domain.
 
 ```yaml
@@ -108,7 +108,7 @@ affinity:
       topologyKey: node-pool
 ```
 
-The above matchLabelKeys and mismatchLabelKeys will be translated to like:
+The above `matchLabelKeys` and `mismatchLabelKeys` will be translated to like:
 
 ```yaml
 kind: Pod
@@ -140,17 +140,17 @@ spec:
           - key: tenant
             operator: NotIn
             values:
-            - service-a 
+            - service-a
         topologyKey: node-pool
 ```
 
-## Getting involved 
+## Getting involved
 
 These features are managed by Kubernetes [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling).
 
 Please join us and share your feedback. We look forward to hearing from you!
 
-## How can I learn more? 
+## How can I learn more?
 
-- [The official document of PodAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
+- [The official document of podAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
-- [KEP-3633: Introduce MatchLabelKeys and MismatchLabelKeys to PodAffinity and PodAntiAffinity](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3633-matchlabelkeys-to-podaffinity/README.md#story-2)
+- [KEP-3633: Introduce matchLabelKeys and mismatchLabelKeys to podAffinity and podAntiAffinity](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3633-matchlabelkeys-to-podaffinity/README.md#story-2)

content/en/blog/_posts/2024-08-20-websocket-transition.md

@@ -0,0 +1,115 @@
+---
+layout: blog
+title: 'Kubernetes 1.31: Streaming Transitions from SPDY to WebSockets'
+date: 2024-08-20
+slug: websockets-transition
+author: >
+  [Sean Sullivan](https://github.com/seans3) (Google)
+  [Shannon Kularathna](https://github.com/shannonxtreme) (Google)
+---
+
+In Kubernetes 1.31, by default kubectl now uses the WebSocket protocol
+instead of SPDY for streaming.
+
+This post describes what these changes mean for you and why these streaming APIs
+matter.
+
+## Streaming APIs in Kubernetes
+
+In Kubernetes, specific endpoints that are exposed as an HTTP or RESTful
+interface are upgraded to streaming connections, which require a streaming
+protocol. Unlike HTTP, which is a request-response protocol, a streaming
+protocol provides a persistent connection that's bi-directional, low-latency,
+and lets you interact in real-time. Streaming protocols support reading and
+writing data between your client and the server, in both directions, over the
+same connection. This type of connection is useful, for example, when you create
+a shell in a running container from your local workstation and run commands in
+the container.
+
+## Why change the streaming protocol?
+
+Before the v1.31 release, Kubernetes used the SPDY/3.1 protocol by default when
+upgrading streaming connections. SPDY/3.1 has been deprecated for eight years,
+and it was never standardized. Many modern proxies, gateways, and load balancers
+no longer support the protocol. As a result, you might notice that commands like
+`kubectl cp`, `kubectl attach`, `kubectl exec`, and `kubectl port-forward`
+stop working when you try to access your cluster through a proxy or gateway.
+
+As of Kubernetes v1.31, SIG API Machinery has modified the streaming
+protocol that a Kubernetes client (such as `kubectl`) uses for these commands
+to the more modern [WebSocket streaming protocol](https://datatracker.ietf.org/doc/html/rfc6455).
+The WebSocket protocol is a currently supported standardized streaming protocol
+that guarantees compatibility and interoperability with different components and
+programming languages. The WebSocket protocol is more widely supported by modern
+proxies and gateways than SPDY.
+
+## How streaming APIs work
+
+Kubernetes upgrades HTTP connections to streaming connections by adding
+specific upgrade headers to the originating HTTP request. For example, an HTTP
+upgrade request for running the `date` command on an `nginx` container within
+a cluster is similar to the following:
+
+```console
+$ kubectl exec -v=8 nginx -- date
+GET https://127.0.0.1:43251/api/v1/namespaces/default/pods/nginx/exec?command=date…
+Request Headers:
+    Connection: Upgrade
+    Upgrade: websocket
+    Sec-Websocket-Protocol: v5.channel.k8s.io
+    User-Agent: kubectl/v1.31.0 (linux/amd64) kubernetes/6911225
+```
+
+If the container runtime supports the WebSocket streaming protocol and at least
+one of the subprotocol versions (e.g. `v5.channel.k8s.io`), the server responds
+with a successful `101 Switching Protocols` status, along with the negotiated
+subprotocol version:
+
+```console
+Response Status: 101 Switching Protocols in 3 milliseconds
+Response Headers:
+    Upgrade: websocket
+    Connection: Upgrade
+    Sec-Websocket-Accept: j0/jHW9RpaUoGsUAv97EcKw8jFM=
+    Sec-Websocket-Protocol: v5.channel.k8s.io
+```
+
+At this point the TCP connection used for the HTTP protocol has changed to a
+streaming connection. Subsequent STDIN, STDOUT, and STDERR data (as well as
+terminal resizing data and process exit code data) for this shell interaction is
+then streamed over this upgraded connection.
+
+## How to use the new WebSocket streaming protocol
+
+If your cluster and kubectl are on version 1.29 or later, there are two
+control plane feature gates and two kubectl environment variables that
+govern the use of the WebSockets rather than SPDY. In Kubernetes 1.31,
+all of the following feature gates are in beta and are enabled by
+default:
+
+- [Feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
+  - `TranslateStreamCloseWebsocketRequests`
+      - `.../exec`
+      - `.../attach`
+  - `PortForwardWebsockets`
+      - `.../port-forward`
+- kubectl feature control environment variables
+  - `KUBECTL_REMOTE_COMMAND_WEBSOCKETS`
+      - `kubectl exec`
+      - `kubectl cp`
+      - `kubectl attach`
+  - `KUBECTL_PORT_FORWARD_WEBSOCKETS`
+      - `kubectl port-forward`
+
+If you're connecting to an older cluster but can manage the feature gate
+settings, turn on both `TranslateStreamCloseWebsocketRequests` (added in
+Kubernetes v1.29) and `PortForwardWebsockets` (added in Kubernetes
+v1.30) to try this new behavior. Version 1.31 of `kubectl` can automatically use
+the new behavior, but you do need to connect to a cluster where the server-side
+features are explicitly enabled.
+
+## Learn more about streaming APIs
+
+- [KEP 4006 - Transitioning from SPDY to WebSockets](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/4006-transition-spdy-to-websockets)
+- [RFC 6455 - The WebSockets Protocol](https://datatracker.ietf.org/doc/html/rfc6455)
+- [Container Runtime Interface streaming explained](https://kubernetes.io/blog/2024/05/01/cri-streaming-explained/)

content/en/blog/_posts/2024-08-21-cgroup-driver-from-cri.md

@@ -0,0 +1,38 @@
+---
+layout: blog
+title: "Kubernetes 1.31: Autoconfiguration For Node Cgroup Driver (beta)"
+date: 2024-08-21
+slug: cri-cgroup-driver-lookup-now-beta
+author: >
+  Peter Hunt (Red Hat)
+---
+
+Historically, configuring the correct cgroup driver has been a pain point for users running new
+Kubernetes clusters. On Linux systems, there are two different cgroup drivers:
+`cgroupfs` and `systemd`. In the past, both the [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+and CRI implementation (like CRI-O or containerd) needed to be configured to use
+the same cgroup driver, or else the kubelet would exit with an error. This was a
+source of headaches for many cluster admins. However, there is light at the end of the tunnel!
+
+## Automated cgroup driver detection
+
+In v1.28.0, the SIG Node community introduced the feature gate
+`KubeletCgroupDriverFromCRI`, which instructs the kubelet to ask the CRI
+implementation which cgroup driver to use. A few minor releases of Kubernetes
+happened whilst we waited for support to land in the major two CRI implementations
+(containerd and CRI-O), but as of v1.31.0, this feature is now beta!
+
+In addition to setting the feature gate, a cluster admin needs to ensure their
+CRI implementation is new enough:
+
+- containerd: Support was added in v2.0.0
+- CRI-O: Support was added in v1.28.0
+
+Then, they should ensure their CRI implementation is configured to the
+cgroup_driver they would like to use.
+
+## Future work
+
+Eventually, support for the kubelet's `cgroupDriver` configuration field will be
+dropped, and the kubelet will fail to start if the CRI implementation isn't new
+enough to have support for this feature.

content/en/blog/_posts/2024-08-22-Fine-grained-SupplementalGroups-control/index.md

@@ -57,7 +57,7 @@ Thus, the group membership defined in `/etc/group` in the container image for th
 
 The _implicitly_ merged group information from `/etc/group` in the container image may cause some concerns particularly in accessing volumes (see [kubernetes/kubernetes#112879](https://issue.k8s.io/112879) for details) because file permission is controlled by uid/gid in Linux. Even worse, the implicit gids from `/etc/group` can not be detected/validated by any policy engines because there is no clue for the implicit group information in the manifest. This can also be a concern for Kubernetes security.
 
-## Fine-grined SupplementalGroups control in a Pod: `SupplementaryGroupsPolicy`
+## Fine-grained SupplementalGroups control in a Pod: `SupplementaryGroupsPolicy`
 
 To tackle the above problem, Kubernetes 1.31 introduces new field `supplementalGroupsPolicy` in Pod's `.spec.securityContext`.
 
@@ -153,8 +153,9 @@ the feature gate manually.
 ## How can I learn more?
 
 <!-- https://github.com/kubernetes/website/pull/46920 -->
-Please check out the [documentation](/docs/tasks/configure-pod-container/security-context/)
+- [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
-for the further details of `supplementalGroupsPolicy`.
+for the further details of `supplementalGroupsPolicy`
+- [KEP-3619: Fine-grained SupplementalGroups control](https://github.com/kubernetes/enhancements/issues/3619)
 
 ## How to get involved?
 

content/en/blog/_posts/2024-08-22-cpumanager-static-policy-distributed-cpu-across-cores/index.md

@@ -0,0 +1,54 @@
+---
+layout: blog
+title: 'Kubernetes v1.31: New Kubernetes CPUManager Static Policy: Distribute CPUs Across Cores'
+date: 2024-08-22
+slug: cpumanager-static-policy-distributed-cpu-across-cores
+author: >
+  [Jiaxin Shan](https://github.com/Jeffwan) (Bytedance)
+---
+
+In Kubernetes v1.31, we are excited to introduce a significant enhancement to CPU management capabilities: the `distribute-cpus-across-cores` option for the [CPUManager static policy](/docs/tasks/administer-cluster/cpu-management-policies/#static-policy-options). This feature is currently in alpha and hidden by default, marking a strategic shift aimed at optimizing CPU utilization and improving system performance across multi-core processors.
+
+## Understanding the feature
+
+Traditionally, Kubernetes' CPUManager tends to allocate CPUs as compactly as possible, typically packing them onto the fewest number of physical cores. However, allocation strategy matters, CPUs on the same physical host still share some resources of the physical core, such as the cache and execution units, etc.
+
+{{< figure src="cpu-cache-architecture.png" alt="cpu-cache-architecture" >}}
+
+While default approach minimizes inter-core communication and can be beneficial under certain scenarios, it also poses a challenge. CPUs sharing a physical core can lead to resource contention, which in turn may cause performance bottlenecks, particularly noticeable in CPU-intensive applications.
+
+The new `distribute-cpus-across-cores` feature addresses this issue by modifying the allocation strategy. When enabled, this policy option instructs the CPUManager to spread out the CPUs (hardware threads) across as many physical cores as possible. This distribution is designed to minimize contention among CPUs sharing the same physical core, potentially enhancing the performance of applications by providing them dedicated core resources.
+
+Technically, within this static policy, the free CPU list is reordered in the manner depicted in the diagram, aiming to allocate CPUs from separate physical cores.
+
+{{< figure src="cpu-ordering.png" alt="cpu-ordering" >}}
+
+
+## Enabling the feature
+
+To enable this feature, users firstly need to add `--cpu-manager-policy=static` kubelet flag or the `cpuManagerPolicy: static` field in KubeletConfiuration. Then user can add `--cpu-manager-policy-options distribute-cpus-across-cores=true` or `distribute-cpus-across-cores=true` to their CPUManager policy options in the Kubernetes configuration or. This setting directs the CPUManager to adopt the new distribution strategy. It is important to note that this policy option cannot currently be used in conjunction with `full-pcpus-only` or `distribute-cpus-across-numa` options.
+
+
+## Current limitations and future directions
+
+As with any new feature, especially one in alpha, there are limitations and areas for future improvement. One significant current limitation is that `distribute-cpus-across-cores` cannot be combined with other policy options that might conflict in terms of CPU allocation strategies. This restriction can affect compatibility with certain workloads and deployment scenarios that rely on more specialized resource management.
+
+Looking forward, we are committed to enhancing the compatibility and functionality of the `distribute-cpus-across-cores` option. Future updates will focus on resolving these compatibility issues, allowing this policy to be combined with other CPUManager policies seamlessly. Our goal is to provide a more flexible and robust CPU allocation framework that can adapt to a variety of workloads and performance demands.
+
+
+## Conclusion
+
+The introduction of the `distribute-cpus-across-cores` policy in Kubernetes CPUManager is a step forward in our ongoing efforts to refine resource management and improve application performance. By reducing the contention on physical cores, this feature offers a more balanced approach to CPU resource allocation, particularly beneficial for environments running heterogeneous workloads. We encourage Kubernetes users to test this new feature and provide feedback, which will be invaluable in shaping its future development.
+
+This draft aims to clearly explain the new feature while setting expectations for its current stage and future improvements.
+
+
+## Further reading
+
+Please check out the [Control CPU Management Policies on the Node](/docs/tasks/administer-cluster/cpu-management-policies/)
+task page to learn more about the CPU Manager, and how it fits in relation to the other node-level resource managers.
+
+
+## Getting involved
+
+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 attend the SIG Node meeting for more details.

content/en/blog/_posts/2024-08-23-kubeadm-v1beta4.md

@@ -19,7 +19,7 @@ I'll explain about the kubeadm v1beta4 configuration format,
 and how to migrate from v1beta3 to v1beta4.
 
 You can read the reference for the v1beta4 configuration format:
-[kubeadm Configuration (v1beta4)]((/docs/reference/config-api/kubeadm-config.v1beta4/)).
+[kubeadm Configuration (v1beta4)](/docs/reference/config-api/kubeadm-config.v1beta4/).
 
 ### A list of changes since v1beta3
 

content/en/docs/concepts/architecture/_index.md

@@ -5,4 +5,201 @@ description: >
   The architectural concepts behind Kubernetes.
 ---
 
-{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="Components of Kubernetes" caption="Kubernetes cluster architecture" class="diagram-large" >}}
+A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes,
+that run containerized applications. Every cluster needs at least one worker node in order to run Pods.
+
+The worker node(s) host the Pods that are the components of the application workload.
+The control plane manages the worker nodes and the Pods in the cluster. In production
+environments, the control plane usually runs across multiple computers and a cluster
+usually runs multiple nodes, providing fault-tolerance and high availability.
+
+This document outlines the various components you need to have for a complete and working Kubernetes cluster.
+
+{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="The control plane (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) and several nodes. Each node is running a kubelet and kube-proxy."
+title="Kubernetes cluster components"
+caption="**Note:** This diagram presents an example reference architecture for a Kubernetes cluster. The actual distribution of components can vary based on specific cluster setups and requirements." class="diagram-large" >}}
+
+## Control plane components
+
+The control plane's components make global decisions about the cluster (for example, scheduling),
+as well as detecting and responding to cluster events (for example, starting up a new
+{{< glossary_tooltip text="pod" term_id="pod">}} when a Deployment's
+`{{< glossary_tooltip text="replicas" term_id="replica" >}}` field is unsatisfied).
+
+Control plane components can be run on any machine in the cluster. However, for simplicity, setup scripts
+typically start all control plane components on the same machine, and do not run user containers on this machine.
+See [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
+for an example control plane setup that runs across multiple machines.
+
+### kube-apiserver
+
+{{< glossary_definition term_id="kube-apiserver" length="all" >}}
+
+### etcd
+
+{{< glossary_definition term_id="etcd" length="all" >}}
+
+### kube-scheduler
+
+{{< glossary_definition term_id="kube-scheduler" length="all" >}}
+
+### kube-controller-manager
+
+{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
+
+There are many different types of controllers. Some examples of them are:
+
+- Node controller: Responsible for noticing and responding when nodes go down.
+- Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.
+- EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).
+- ServiceAccount controller: Create default ServiceAccounts for new namespaces.
+
+The above is not an exhaustive list.
+
+### cloud-controller-manager
+
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+
+The cloud-controller-manager only runs controllers that are specific to your cloud provider.
+If you are running Kubernetes on your own premises, or in a learning environment inside your
+own PC, the cluster does not have a cloud controller manager.
+
+As with the kube-controller-manager, the cloud-controller-manager combines several logically
+independent control loops into a single binary that you run as a single process. You can scale
+horizontally (run more than one copy) to improve performance or to help tolerate failures.
+
+The following controllers can have cloud provider dependencies:
+
+- Node controller: For checking the cloud provider to determine if a node has been
+  deleted in the cloud after it stops responding
+- Route controller: For setting up routes in the underlying cloud infrastructure
+- Service controller: For creating, updating and deleting cloud provider load balancers
+
+## Node components
+
+Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
+
+### kubelet
+
+{{< glossary_definition term_id="kubelet" length="all" >}}
+
+### kube-proxy (optional) {#kube-proxy}
+
+{{< glossary_definition term_id="kube-proxy" length="all" >}}
+If you use a [network plugin](#network-plugins) that implements packet forwarding for Services
+by itself, and providing equivalent behavior to kube-proxy, then you do not need to run
+kube-proxy on the nodes in your cluster.
+
+### Container runtime
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## Addons
+
+Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
+{{< glossary_tooltip term_id="deployment" >}}, etc) to implement cluster features.
+Because these are providing cluster-level features, namespaced resources for
+addons belong within the `kube-system` namespace.
+
+Selected addons are described below; for an extended list of available addons,
+please see [Addons](/docs/concepts/cluster-administration/addons/).
+
+### DNS
+
+While the other addons are not strictly required, all Kubernetes clusters should have
+[cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it.
+
+Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment,
+which serves DNS records for Kubernetes services.
+
+Containers started by Kubernetes automatically include this DNS server in their DNS searches.
+
+### Web UI (Dashboard)
+
+[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose,
+web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications
+running in the cluster, as well as the cluster itself.
+
+### Container resource monitoring
+
+[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
+records generic time-series metrics about containers in a central database, and provides a UI for browsing that data.
+
+### Cluster-level Logging
+
+A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible
+for saving container logs to a central log store with a search/browsing interface.
+
+### Network plugins
+
+[Network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins)
+are software components that implement the container network interface (CNI) specification.
+They are responsible for allocating IP addresses to pods and enabling them to communicate
+with each other within the cluster.
+
+## Architecture variations
+
+While the core components of Kubernetes remain consistent, the way they are deployed and
+managed can vary. Understanding these variations is crucial for designing and maintaining
+Kubernetes clusters that meet specific operational needs.
+
+### Control plane deployment options
+
+The control plane components can be deployed in several ways:
+
+Traditional deployment
+: Control plane components run directly on dedicated machines or VMs, often managed as systemd services.
+
+Static Pods
+: Control plane components are deployed as static Pods, managed by the kubelet on specific nodes.
+  This is a common approach used by tools like kubeadm.
+
+Self-hosted
+: The control plane runs as Pods within the Kubernetes cluster itself, managed by Deployments
+  and StatefulSets or other Kubernetes primitives.
+
+Managed Kubernetes services
+: Cloud providers often abstract away the control plane, managing its components as part of their service offering.
+
+### Workload placement considerations
+
+The placement of workloads, including the control plane components, can vary based on cluster size,
+performance requirements, and operational policies:
+
+- In smaller or development clusters, control plane components and user workloads might run on the same nodes.
+- Larger production clusters often dedicate specific nodes to control plane components,
+  separating them from user workloads.
+- Some organizations run critical add-ons or monitoring tools on control plane nodes.
+
+### Cluster management tools
+
+Tools like kubeadm, kops, and Kubespray offer different approaches to deploying and managing clusters,
+each with its own method of component layout and management.
+
+The flexibility of Kubernetes architecture allows organizations to tailor their clusters to specific needs,
+balancing factors such as operational complexity, performance, and management overhead.
+
+### Customization and extensibility
+
+Kubernetes architecture allows for significant customization:
+
+- Custom schedulers can be deployed to work alongside the default Kubernetes scheduler or to replace it entirely.
+- API servers can be extended with CustomResourceDefinitions and API Aggregation.
+- Cloud providers can integrate deeply with Kubernetes using the cloud-controller-manager.
+
+The flexibility of Kubernetes architecture allows organizations to tailor their clusters to specific needs,
+balancing factors such as operational complexity, performance, and management overhead.
+
+## {{% heading "whatsnext" %}}
+
+Learn more about the following:
+
+- [Nodes](/docs/concepts/architecture/nodes/) and
+  [their communication](/docs/concepts/architecture/control-plane-node-communication/)
+  with the control plane.
+- Kubernetes [controllers](/docs/concepts/architecture/controller/).
+- [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) which is the default scheduler for Kubernetes.
+- Etcd's official [documentation](https://etcd.io/docs/).
+- Several [container runtimes](/docs/setup/production-environment/container-runtimes/) in Kubernetes.
+- Integrating with cloud providers using [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
+- [kubectl](/docs/reference/generated/kubectl/kubectl-commands) commands.

content/en/docs/concepts/architecture/control-plane-node-communication.md

@@ -120,7 +120,7 @@ up the Konnectivity service in your cluster.
 
 ## {{% heading "whatsnext" %}}
 
-* Read about the [Kubernetes control plane components](/docs/concepts/overview/components/#control-plane-components)
+* Read about the [Kubernetes control plane components](/docs/concepts/architecture/#control-plane-components)
 * Learn more about [Hubs and Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors)
 * Learn how to [Secure a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/) 
 * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)

content/en/docs/concepts/architecture/controller.md

@@ -161,7 +161,7 @@ controller does.
 
 ## {{% heading "whatsnext" %}}
 
-* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
+* Read about the [Kubernetes control plane](/docs/concepts/architecture/#control-plane-components)
 * Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/)
 * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
 * If you want to write your own controller, see

content/en/docs/concepts/architecture/garbage-collection.md

@@ -144,9 +144,8 @@ until disk usage reaches the `LowThresholdPercent` value.
 As a beta feature, you can specify the maximum time a local image can be unused for,
 regardless of disk usage. This is a kubelet setting that you configure for each node.
 
-To configure the setting, enable the `ImageMaximumGCAge`
+To configure the setting, you need to set a value for the `imageMaximumGCAge` 
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kubelet,
+field in the kubelet configuration file.
-and also set a value for the `imageMaximumGCAge` field in the kubelet configuration file.
 
 The value is specified as a Kubernetes _duration_; 
 Valid time units for the `imageMaximumGCAge` field in the kubelet configuration file are:

content/en/docs/concepts/architecture/nodes.md

@@ -23,7 +23,7 @@ and contains the services necessary to run
 Typically you have several nodes in a cluster; in a learning or resource-limited
 environment, you might have only one node.
 
-The [components](/docs/concepts/overview/components/#node-components) on a node include the
+The [components](/docs/concepts/architecture/#node-components) on a node include the
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, a
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the
 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
@@ -352,7 +352,7 @@ see the blog-post about [Kubernetes 1.28: NodeSwap graduates to Beta1](/blog/202
 
 Learn more about the following:
 
-* [Components](/docs/concepts/overview/components/#node-components) that make up a node.
+* [Components](/docs/concepts/architecture/#node-components) that make up a node.
 * [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
 * [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
   section of the architecture design document.

content/en/docs/concepts/cluster-administration/addons.md

@@ -96,8 +96,6 @@ installation instructions. The list does not try to be exhaustive.
 
 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)
   is a dashboard web interface for Kubernetes.
-* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a
-  tool for visualizing your containers, Pods, Services and more.
 
 ## Infrastructure
 

content/en/docs/concepts/configuration/configmap.md

@@ -221,6 +221,54 @@ in a Pod:
    in the specified environment variables.
 
 This is an example of defining a ConfigMap as a pod environment variable:
+
+The following ConfigMap (myconfigmap.yaml) stores two properties: username and access_level:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: myconfigmap
+data:
+  username: k8s-admin
+  access_level: "1"
+```
+
+The following command will create the ConfigMap object:
+
+```shell
+kubectl apply -f myconfigmap.yaml
+```
+
+The following Pod consumes the content of the ConfigMap as environment variables:
+
+{{% code_sample file="configmap/env-configmap.yaml" %}}
+
+The `envFrom` field instructs Kubernetes to create environment variables from the sources nested within it.
+The inner `configMapRef` refers to a ConfigMap by its name and selects all its key-value pairs.
+Add the Pod to your cluster, then retrieve its logs to see the output from the printenv command.
+This should confirm that the two key-value pairs from the ConfigMap have been set as environment variables:
+
+```shell
+kubectl apply -f env-configmap.yaml
+```
+```shell
+kubectl logs pod/ env-configmap
+```
+The output is similar to this:
+```console
+...
+username: "k8s-admin"
+access_level: "1"
+...
+```
+
+Sometimes a Pod won't require access to all the values in a ConfigMap.
+For example, you could have another Pod which only uses the username value from the ConfigMap.
+For this use case, you can use the `env.valueFrom` syntax instead, which lets you select individual keys in
+a ConfigMap. The name of the environment variable can also be different from the key within the ConfigMap.
+For example:
+
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -236,9 +284,13 @@ spec:
         configMapKeyRef:
           name: myconfigmap
           key: username
-
 ```
 
+In the Pod created from this manifest, you will see that the environment variable
+`CONFIGMAP_USERNAME` is set to the value of the `username` value from the ConfigMap.
+Other keys from the ConfigMap data are not copied into the environment.
+
+
 It's important to note that the range of characters allowed for environment
 variable names in pods is [restricted](/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config).
 If any keys do not meet the rules, those keys are not made available to your container, though

content/en/docs/concepts/configuration/liveness-readiness-startup-probes.md

@@ -40,6 +40,6 @@ A startup probe verifies whether the application within a container is started.
 
 If such a probe is configured, it disables liveness and readiness checks until it succeeds.
 
-This type of probe is only executed at startup, unlike readiness probes, which are run periodically.
+This type of probe is only executed at startup, unlike liveness and readiness probes, which are run periodically.
 
-* Read more about the [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes).
+* Read more about the [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes).

content/en/docs/concepts/configuration/manage-resources-containers.md

@@ -276,7 +276,7 @@ If you are administering a cluster or namespace, you can also set
 you may also want to define a [LimitRange](/docs/concepts/policy/limit-range/)
 for additional enforcement.
 If you specify a `spec.containers[].resources.limits.memory` for each Pod,
-then the muximum size of an `emptyDir` volume will be the pod's memory limit.
+then the maximum size of an `emptyDir` volume will be the pod's memory limit.
 
 As an alternative, a cluster administrator can enforce size limits for
 `emptyDir` volumes in new Pods using a policy mechanism such as

content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -16,7 +16,7 @@ The additional APIs can either be ready-made solutions such as a
 [metrics server](https://github.com/kubernetes-sigs/metrics-server), or APIs that you develop yourself.
 
 The aggregation layer is different from
-[Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
+[Custom Resource Definitions](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
 which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
 recognise new kinds of object.
 

content/en/docs/concepts/extend-kubernetes/compute-storage-net/_index.md

@@ -35,7 +35,7 @@ fabric that links Pods together.
 
 * [Network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 
-  A network plugin allow Kubernetes to work with different networking topologies and technologies.
+  Network plugins allow Kubernetes to work with different networking topologies and technologies.
   Your Kubernetes cluster needs a _network plugin_ in order to have a working Pod network
   and to support other aspects of the Kubernetes network model.
 

content/en/docs/concepts/overview/_index.md

@@ -22,75 +22,12 @@ This page is an overview of Kubernetes.
 
 <!-- body -->
 
-Kubernetes is a portable, extensible, open source platform for managing containerized
-workloads and services, that facilitates both declarative configuration and automation.
-It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
-
 The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation
 results from counting the eight letters between the "K" and the "s". Google open-sourced the
 Kubernetes project in 2014. Kubernetes combines
 [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running
 production workloads at scale with best-of-breed ideas and practices from the community.
 
-## Going back in time
-
-Let's take a look at why Kubernetes is so useful by going back in time.
-
-![Deployment evolution](/images/docs/Container_Evolution.svg)
-
-**Traditional deployment era:**
-Early on, organizations ran applications on physical servers. There was no way to define
-resource boundaries for applications in a physical server, and this caused resource
-allocation issues. For example, if multiple applications run on a physical server, there
-can be instances where one application would take up most of the resources, and as a result,
-the other applications would underperform. A solution for this would be to run each application
-on a different physical server. But this did not scale as resources were underutilized, and it
-was expensive for organizations to maintain many physical servers.
-
-**Virtualized deployment era:** As a solution, virtualization was introduced. It allows you
-to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization
-allows applications to be isolated between VMs and provides a level of security as the
-information of one application cannot be freely accessed by another application.
-
-Virtualization allows better utilization of resources in a physical server and allows
-better scalability because an application can be added or updated easily, reduces
-hardware costs, and much more. With virtualization you can present a set of physical
-resources as a cluster of disposable virtual machines.
-
-Each VM is a full machine running all the components, including its own operating
-system, on top of the virtualized hardware.
-
-**Container deployment era:** Containers are similar to VMs, but they have relaxed
-isolation properties to share the Operating System (OS) among the applications.
-Therefore, containers are considered lightweight. Similar to a VM, a container
-has its own filesystem, share of CPU, memory, process space, and more. As they
-are decoupled from the underlying infrastructure, they are portable across clouds
-and OS distributions.
-
-Containers have become popular because they provide extra benefits, such as:
-
-* Agile application creation and deployment: increased ease and efficiency of
-  container image creation compared to VM image use.
-* Continuous development, integration, and deployment: provides for reliable
-  and frequent container image build and deployment with quick and efficient
-  rollbacks (due to image immutability).
-* Dev and Ops separation of concerns: create application container images at
-  build/release time rather than deployment time, thereby decoupling
-  applications from infrastructure.
-* Observability: not only surfaces OS-level information and metrics, but also
-  application health and other signals.
-* Environmental consistency across development, testing, and production: runs
-  the same on a laptop as it does in the cloud.
-* Cloud and OS distribution portability: runs on Ubuntu, RHEL, CoreOS, on-premises,
-  on major public clouds, and anywhere else.
-* Application-centric management: raises the level of abstraction from running an
-  OS on virtual hardware to running an application on an OS using logical resources.
-* Loosely coupled, distributed, elastic, liberated micro-services: applications are
-  broken into smaller, independent pieces and can be deployed and managed dynamically –
-  not a monolithic stack running on one big single-purpose machine.
-* Resource isolation: predictable application performance.
-* Resource utilization: high efficiency and density.
-
 ## Why you need Kubernetes and what it can do {#why-you-need-kubernetes-and-what-can-it-do}
 
 Containers are a good way to bundle and run your applications. In a production
@@ -174,6 +111,71 @@ Kubernetes:
   It shouldn't matter how you get from A to C. Centralized control is also not required. This
   results in a system that is easier to use and more powerful, robust, resilient, and extensible.
 
+## Historical context for Kubernetes {#going-back-in-time}
+
+Let's take a look at why Kubernetes is so useful by going back in time.
+
+![Deployment evolution](/images/docs/Container_Evolution.svg)
+
+**Traditional deployment era:**
+
+Early on, organizations ran applications on physical servers. There was no way to define
+resource boundaries for applications in a physical server, and this caused resource
+allocation issues. For example, if multiple applications run on a physical server, there
+can be instances where one application would take up most of the resources, and as a result,
+the other applications would underperform. A solution for this would be to run each application
+on a different physical server. But this did not scale as resources were underutilized, and it
+was expensive for organizations to maintain many physical servers.
+
+**Virtualized deployment era:**
+
+As a solution, virtualization was introduced. It allows you
+to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization
+allows applications to be isolated between VMs and provides a level of security as the
+information of one application cannot be freely accessed by another application.
+
+Virtualization allows better utilization of resources in a physical server and allows
+better scalability because an application can be added or updated easily, reduces
+hardware costs, and much more. With virtualization you can present a set of physical
+resources as a cluster of disposable virtual machines.
+
+Each VM is a full machine running all the components, including its own operating
+system, on top of the virtualized hardware.
+
+**Container deployment era:**
+
+Containers are similar to VMs, but they have relaxed
+isolation properties to share the Operating System (OS) among the applications.
+Therefore, containers are considered lightweight. Similar to a VM, a container
+has its own filesystem, share of CPU, memory, process space, and more. As they
+are decoupled from the underlying infrastructure, they are portable across clouds
+and OS distributions.
+
+Containers have become popular because they provide extra benefits, such as:
+
+* Agile application creation and deployment: increased ease and efficiency of
+  container image creation compared to VM image use.
+* Continuous development, integration, and deployment: provides for reliable
+  and frequent container image build and deployment with quick and efficient
+  rollbacks (due to image immutability).
+* Dev and Ops separation of concerns: create application container images at
+  build/release time rather than deployment time, thereby decoupling
+  applications from infrastructure.
+* Observability: not only surfaces OS-level information and metrics, but also
+  application health and other signals.
+* Environmental consistency across development, testing, and production: runs
+  the same on a laptop as it does in the cloud.
+* Cloud and OS distribution portability: runs on Ubuntu, RHEL, CoreOS, on-premises,
+  on major public clouds, and anywhere else.
+* Application-centric management: raises the level of abstraction from running an
+  OS on virtual hardware to running an application on an OS using logical resources.
+* Loosely coupled, distributed, elastic, liberated micro-services: applications are
+  broken into smaller, independent pieces and can be deployed and managed dynamically –
+  not a monolithic stack running on one big single-purpose machine.
+* Resource isolation: predictable application performance.
+* Resource utilization: high efficiency and density.
+
+
 ## {{% heading "whatsnext" %}}
 
 * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)

content/en/docs/concepts/overview/components.md

@@ -4,150 +4,86 @@ reviewers:
 title: Kubernetes Components
 content_type: concept
 description: >
-  A Kubernetes cluster consists of the components that are a part of the control
+  An overview of the key components that make up a Kubernetes cluster.
-  plane and a set of machines called nodes.
+weight: 10
-weight: 30
+card:
-card: 
   title: Components of a cluster
   name: concepts
   weight: 20
 ---
 
 <!-- overview -->
-When you deploy Kubernetes, you get a cluster.
-{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
 
-This document outlines the various components you need to have for
+This page provides a high-level overview of the essential components that make up a Kubernetes cluster.
-a complete and working Kubernetes cluster.
 
 {{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="The components of a Kubernetes cluster" class="diagram-large" clicktozoom="true" >}}
 
 <!-- body -->
-## Control Plane Components
 
-The control plane's components make global decisions about the cluster (for example, scheduling),
+## Core Components
-as well as detecting and responding to cluster events (for example, starting up a new
-{{< glossary_tooltip text="pod" term_id="pod">}} when a Deployment's
-`{{< glossary_tooltip text="replicas" term_id="replica" >}}` field is unsatisfied).
 
-Control plane components can be run on any machine in the cluster. However,
+A Kubernetes cluster consists of a control plane and one or more worker nodes.
-for simplicity, setup scripts typically start all control plane components on
+Here's a brief overview of the main components:
-the same machine, and do not run user containers on this machine. See
-[Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
-for an example control plane setup that runs across multiple machines.
 
-### kube-apiserver
+### Control Plane Components
 
-{{< glossary_definition term_id="kube-apiserver" length="all" >}}
+Manage the overall state of the cluster:
 
-### etcd
+[kube-apiserver](/docs/concepts/architecture/#kube-apiserver)
+: The core component server that exposes the Kubernetes HTTP API
 
-{{< glossary_definition term_id="etcd" length="all" >}}
+[etcd](/docs/concepts/architecture/#etcd)
+: Consistent and highly-available key value store for all API server data
 
-### kube-scheduler
+[kube-scheduler](/docs/concepts/architecture/#kube-scheduler)
+: Looks for Pods not yet bound to a node, and assigns each Pod to a suitable node.
 
-{{< glossary_definition term_id="kube-scheduler" length="all" >}}
+[kube-controller-manager](/docs/concepts/architecture/#kube-controller-manager)
+: Runs {{< glossary_tooltip text="controllers" term_id="controller" >}} to implement Kubernetes API behavior.
 
-### kube-controller-manager
+[cloud-controller-manager](/docs/concepts/architecture/#cloud-controller-manager) (optional)
+: Integrates with underlying cloud provider(s).
 
-{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
+### Node Components
 
-There are many different types of controllers. Some examples of them are:
+Run on every node, maintaining running pods and providing the Kubernetes runtime environment:
 
-  * Node controller: Responsible for noticing and responding when nodes go down.
+[kubelet](/docs/concepts/architecture/#kubelet)
-  * Job controller: Watches for Job objects that represent one-off tasks, then creates
+: Ensures that Pods are running, including their containers.
-    Pods to run those tasks to completion.
-  * EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).
-  * ServiceAccount controller: Create default ServiceAccounts for new namespaces.
 
-The above is not an exhaustive list.
+[kube-proxy](/docs/concepts/architecture/#kube-proxy) (optional)
+: Maintains network rules on nodes to implement {{< glossary_tooltip text="Services" term_id="service" >}}.
 
-### cloud-controller-manager
+[Container runtime](/docs/concepts/architecture/#container-runtime)
+: Software responsible for running containers. Read
+  [Container Runtimes](/docs/setup/production-environment/container-runtimes/) to learn more.
 
-{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+{{% thirdparty-content single="true" %}}
 
-The cloud-controller-manager only runs controllers that are specific to your cloud provider.
+Your cluster may require additional software on each node; for example, you might also
-If you are running Kubernetes on your own premises, or in a learning environment inside your
+run [systemd](https://systemd.io/) on a Linux node to supervise local components.
-own PC, the cluster does not have a cloud controller manager.
-
-As with the kube-controller-manager, the cloud-controller-manager combines several logically
-independent control loops into a single binary that you run as a single process. You can
-scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
-
-The following controllers can have cloud provider dependencies:
-
-  * Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
-  * Route controller: For setting up routes in the underlying cloud infrastructure
-  * Service controller: For creating, updating and deleting cloud provider load balancers
-
-## Node Components
-
-Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
-
-### kubelet
-
-{{< glossary_definition term_id="kubelet" length="all" >}}
-
-### kube-proxy
-
-{{< glossary_definition term_id="kube-proxy" length="all" >}}
-
-### Container runtime
-
-{{< glossary_definition term_id="container-runtime" length="all" >}}
 
 ## Addons
 
-Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
+Addons extend the functionality of Kubernetes. A few important examples include:
-{{< glossary_tooltip term_id="deployment" >}}, etc)
-to implement cluster features. Because these are providing cluster-level features, namespaced resources
-for addons belong within the `kube-system` namespace.
 
-Selected addons are described below; for an extended list of available addons, please
+[DNS](/docs/concepts/architecture/#dns)
-see [Addons](/docs/concepts/cluster-administration/addons/).
+: For cluster-wide DNS resolution
 
-### DNS
+[Web UI](/docs/concepts/architecture/#web-ui-dashboard) (Dashboard)
+: For cluster management via a web interface
 
-While the other addons are not strictly required, all Kubernetes clusters should have
+[Container Resource Monitoring](/docs/concepts/architecture/#container-resource-monitoring)
-[cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it.
+: For collecting and storing container metrics
 
-Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment,
+[Cluster-level Logging](/docs/concepts/architecture/#cluster-level-logging)
-which serves DNS records for Kubernetes services.
+: For saving container logs to a central log store
 
-Containers started by Kubernetes automatically include this DNS server in their DNS searches.
+## Flexibility in Architecture
 
-### Web UI (Dashboard)
+Kubernetes allows for flexibility in how these components are deployed and managed.
+The architecture can be adapted to various needs, from small development environments
+to large-scale production deployments.
 
-[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose,
+For more detailed information about each component and various ways to configure your
-web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications
+cluster architecture, see the [Cluster Architecture](/docs/concepts/architecture/) page.
-running in the cluster, as well as the cluster itself.
-
-### Container Resource Monitoring
-
-[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
-records generic time-series metrics
-about containers in a central database, and provides a UI for browsing that data.
-
-### Cluster-level Logging
-
-A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
-saving container logs to a central log store with search/browsing interface.
-
-### Network Plugins
-
-[Network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins) are software
-components that implement the container network interface (CNI) specification. They are responsible for
-allocating IP addresses to pods and enabling them to communicate with each other within the cluster.
-
-
-## {{% heading "whatsnext" %}}
-
-Learn more about the following:
-   * [Nodes](/docs/concepts/architecture/nodes/) and [their communication](/docs/concepts/architecture/control-plane-node-communication/)
-     with the control plane.
-   * Kubernetes [controllers](/docs/concepts/architecture/controller/).
-   * [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) which is the default scheduler for Kubernetes.
-   * Etcd's official [documentation](https://etcd.io/docs/).
-   * Several [container runtimes](/docs/setup/production-environment/container-runtimes/) in Kubernetes.
-   * Integrating with cloud providers using [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
-   * [kubectl](/docs/reference/generated/kubectl/kubectl-commands) commands.

content/en/docs/concepts/overview/kubernetes-api.md

@@ -65,8 +65,8 @@ the Discovery API. This includes the following for each resource:
 - Alternative names
 - Group, version, kind
 
-The API is available both aggregated and unaggregated form. The aggregated
+The API is available in both aggregated and unaggregated form. The aggregated
-discovery serves two endpoints while the unaggregated discovery serves a
+discovery serves two endpoints, while the unaggregated discovery serves a
 separate endpoint for each group version.
 
 ### Aggregated discovery

content/en/docs/concepts/overview/working-with-objects/_index.md

@@ -1,7 +1,7 @@
 ---
 title: Objects In Kubernetes
 content_type: concept
-weight: 10
+weight: 30
 description: >
   Kubernetes objects are persistent entities in the Kubernetes system.
   Kubernetes uses these entities to represent the state of your cluster.

content/en/docs/concepts/overview/working-with-objects/labels.md

@@ -201,8 +201,11 @@ For example: `partition in (customerA, customerB),environment!=qa`.
 
 ### LIST and WATCH filtering
 
-LIST and WATCH operations may specify label selectors to filter the sets of objects
+For **list** and **watch** operations, you can specify label selectors to filter the sets of objects
-returned using a query parameter. Both requirements are permitted
+returned; you specify the filter using a query parameter.
+(To learn in detail about watches in Kubernetes, read
+[efficient detection of changes](/docs/reference/using-api/api-concepts/#efficient-detection-of-changes)).
+Both requirements are permitted
 (presented here as they would appear in a URL query string):
 
 * _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`

content/en/docs/concepts/overview/working-with-objects/namespaces.md

@@ -61,7 +61,7 @@ Creation and deletion of namespaces are described in the
 [Admin Guide documentation for namespaces](/docs/tasks/administer-cluster/namespaces).
 
 {{< note >}}
-    Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
 {{< /note >}}
 
 ### Viewing namespaces

content/en/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md

@@ -34,18 +34,17 @@ handles allocation in cooperation with the Kubernetes scheduler.
 ## {{% heading "prerequisites" %}}
 
 Kubernetes v{{< skew currentVersion >}} includes cluster-level API support for
-dynamic resource allocation, but it [needs to be
+dynamic resource allocation, but it [needs to be enabled](#enabling-dynamic-resource-allocation)
-enabled](#enabling-dynamic-resource-allocation) explicitly.  You also must
+explicitly. You also must install a resource driver for specific resources that
-install a resource driver for specific resources that are meant to be managed
+are meant to be managed using this API. If you are not running Kubernetes
-using this API.  If you are not running Kubernetes v{{< skew currentVersion>}},
+v{{< skew currentVersion>}}, check the documentation for that version of Kubernetes.
-check the documentation for that version of Kubernetes.
 
 <!-- body -->
 
 ## API
 
-The `resource.k8s.io/v1alpha3` {{< glossary_tooltip text="API group"
+The `resource.k8s.io/v1alpha3`
-term_id="api-group" >}} provides these types:
+{{< glossary_tooltip text="API group" term_id="api-group" >}} provides these types:
 
 ResourceClaim
 : Describes a request for access to resources in the cluster,
@@ -268,12 +267,10 @@ the `.spec.nodeName` field and to use a node selector instead.
 ## Enabling dynamic resource allocation
 
 Dynamic resource allocation is an *alpha feature* and only enabled when the
-`DynamicResourceAllocation` [feature
+`DynamicResourceAllocation` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
+and the `resource.k8s.io/v1alpha3` {{< glossary_tooltip text="API group" term_id="api-group" >}}
-`resource.k8s.io/v1alpha3` {{< glossary_tooltip text="API group"
+are enabled. For details on that, see the `--feature-gates` and `--runtime-config`
-term_id="api-group" >}} are enabled. For details on that, see the
+[kube-apiserver parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
-`--feature-gates` and `--runtime-config` [kube-apiserver
-parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
 kube-scheduler, kube-controller-manager and kubelet also need the feature gate.
 
 When a resource driver uses a control plane controller, then the
@@ -281,7 +278,7 @@ When a resource driver uses a control plane controller, then the
 `DynamicResourceAllocation`.
 
 A quick check whether a Kubernetes cluster supports the feature is to list
-ResourceClass objects with:
+DeviceClass objects with:
 
 ```shell
 kubectl get deviceclasses
@@ -315,7 +312,7 @@ be installed. Please refer to the driver's documentation for details.
 
 ## {{% heading "whatsnext" %}}
 
- - For more information on the design, see the
+- For more information on the design, see the
-   [Structured Parameters with Structured Parameters](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4381-dra-structured-parameters)
+  [Dynamic Resource Allocation with Structured Parameters](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4381-dra-structured-parameters)
-   and the
+  and the
-   [Dynamic Resource Allocation with Control Plane Controller](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md) KEPs.
+  [Dynamic Resource Allocation with Control Plane Controller](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md) KEPs.

content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -85,8 +85,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the
 
 There are two special cases:
 
-An empty `key` with operator `Exists` matches all keys, values and effects which means this
+If the `key` is empty, then the `operator` must be `Exists`, which matches all keys and values. Note that the `effect` still needs to be matched at the same time.
-will tolerate everything.
 
 An empty `effect` matches all effects with key `key1`.
 

content/en/docs/concepts/security/cloud-native-security.md

@@ -24,7 +24,7 @@ There are localized versions available of this whitepaper; if you can link to on
 when localizing, that's even better.
 {{< /comment >}}
 
-The CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
+The CNCF [white paper](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
 on cloud native security defines security controls and practices that are
 appropriate to different _lifecycle phases_.
 
@@ -204,7 +204,7 @@ logs are both tamper-proof and confidential.
 
 ### Cloud native security {#further-reading-cloud-native}
 
-* CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
+* CNCF [white paper](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
   on cloud native security.
 * CNCF [white paper](https://github.com/cncf/tag-security/blob/f80844baaea22a358f5b20dca52cd6f72a32b066/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)
   on good practices for securing a software supply chain.

content/en/docs/concepts/services-networking/_index.md

@@ -7,58 +7,103 @@ description: >
 
 ## The Kubernetes network model
 
-Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address
+The Kubernetes network model is built out of several pieces:
-(one address per IP address family). 
-This means you do not need to explicitly create links between `Pods` and you 
-almost never need to deal with mapping container ports to host ports.  
-This creates a clean, backwards-compatible model where `Pods` can be treated 
-much like VMs or physical hosts from the perspectives of port allocation, 
-naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), 
-application configuration, and migration.
 
-Kubernetes imposes the following fundamental requirements on any networking
+  * Each [Pod](/docs/concepts/workloads/pods/) in a cluster gets its
-implementation (barring any intentional network segmentation policies):
+    own unique cluster-wide IP address.
 
-   * pods can communicate with all other pods on any other [node](/docs/concepts/architecture/nodes/) 
+      * A pod has its own private network namespace which is shared by
-     without NAT
+        all of the containers within the pod. Processes running in
-   * agents on a node (e.g. system daemons, kubelet) can communicate with all
+        different containers in the same pod can communicate with each
-     pods on that node
+        other over `localhost`.
 
-{{< note >}}
+  * The _pod network_ (also called a cluster network) handles communication
-For those platforms that support `Pods` running in the host network (such as Linux), when pods are attached to the host network of a node they can still communicate with all pods on all nodes without NAT.
+    between pods. It ensures that (barring intentional network
-{{< /note >}}
+    segmentation):
 
-This model is not only less complex overall, but it is principally compatible
+      * All pods can communicate with all other pods, whether they are
-with the desire for Kubernetes to enable low-friction porting of apps from VMs
+        on the same [node](/docs/concepts/architecture/nodes/) or on
-to containers.  If your job previously ran in a VM, your VM had an IP and could
+        different nodes. Pods can communicate with each other
-talk to other VMs in your project.  This is the same basic model.
+        directly, without the use of proxies or address translation
+        (NAT).
 
-Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod`
+          * (On Windows, this rule does not apply to host-network pods.)
-share their network namespaces - including their IP address and MAC address.
-This means that containers within a `Pod` can all reach each other's ports on
-`localhost`. This also means that containers within a `Pod` must coordinate port
-usage, but this is no different from processes in a VM.  This is called the
-"IP-per-pod" model.
 
-How this is implemented is a detail of the particular container runtime in use.
+      * Agents on a node (such as system daemons, or kubelet) can
+        communicate with all pods on that node.
 
-It is possible to request ports on the `Node` itself which forward to your `Pod`
+  * The [Service](/docs/concepts/services-networking/service/) API
-(called host ports), but this is a very niche operation. How that forwarding is
+    lets you provide a stable (long lived) IP address or hostname for a service implemented
-implemented is also a detail of the container runtime. The `Pod` itself is
+    by one or more backend pods, where the individual pods making up
-blind to the existence or non-existence of host ports.
+    the service can change over time.
 
-Kubernetes networking addresses four concerns:
+      * Kubernetes automatically manages
-- Containers within a Pod [use networking to communicate](/docs/concepts/services-networking/dns-pod-service/) via loopback.
+        [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)
-- Cluster networking provides communication between different Pods.
+        objects to provide information about the pods currently
-- The [Service](/docs/concepts/services-networking/service/) API lets you
+        backing a Service.
-  [expose an application running in Pods](/docs/tutorials/services/connect-applications-service/)
+
-  to be reachable from outside your cluster.
+      * A service proxy implementation monitors the `Service` and
-  - [Ingress](/docs/concepts/services-networking/ingress/) provides extra functionality
+        `EndpointSlice` objects, and programs the data plane to route
-    specifically for exposing HTTP applications, websites and APIs.
+        service traffic to its backends, by using operating system or
-  - [Gateway API](/docs/concepts/services-networking/gateway/) is an {{<glossary_tooltip text="add-on" term_id="addons">}}
+        cloud provider APIs to intercept or rewrite packets.
-    that provides an expressive, extensible, and role-oriented family of API kinds for modeling service networking.
+
-- You can also use Services to
+  * The [Gateway](/docs/concepts/services-networking/gateway/) API
-  [publish services only for consumption inside your cluster](/docs/concepts/services-networking/service-traffic-policy/).
+    (or its predecessor,
+    [Ingress](/docs/concepts/services-networking/ingress/)) allows
+    you to make Services accessible to clients that are outside the cluster.
+
+      * A simpler, but less-configurable, mechanism for cluster
+        ingress is available via the Service API's [`type:
+        LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer),
+        when using a supported {{< glossary_tooltip term_id="cloud-provider">}}.
+
+  * [NetworkPolicy](/docs/concepts/services-networking/network-policies) is a built-in
+    Kubernetes API that
+    allows you to control traffic between pods, or between pods and
+    the outside world.
+
+In older container systems, there was no automatic connectivity
+between containers on different hosts, and so it was often necessary
+to explicitly create links between containers, or to map container
+ports to host ports to make them reachable by containers on other
+hosts. This is not needed in Kubernetes; Kubernetes's model is that
+pods can be treated much like VMs or physical hosts from the
+perspectives of port allocation, naming, service discovery, load
+balancing, application configuration, and migration.
+
+Only a few parts of this model are implemented by Kubernetes itself.
+For the other parts, Kubernetes defines the APIs, but the
+corresponding functionality is provided by external components, some
+of which are optional:
+
+  * Pod network namespace setup is handled by system-level software
+    implementing the [Container Runtime
+    Interface](/docs/concepts/architecture/cri.md).
+
+  * The pod network itself is managed by a [pod network
+    implementation](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
+    On Linux, most container runtimes use the
+    {{< glossary_tooltip text="Container Networking Interface (CNI)" term_id="cni" >}}
+    to interact with the pod network implementation, so these
+    implementations are often called _CNI plugins_.
+
+  * Kubernetes provides a default implementation of service proxying,
+    called {{< glossary_tooltip term_id="kube-proxy">}}, but some pod
+    network implementations instead use their own service proxy that
+    is more tightly integrated with the rest of the implementation.
+
+  * NetworkPolicy is generally also implemented by the pod network
+    implementation. (Some simpler pod network implementations don't
+    implement NetworkPolicy, or an administrator may choose to
+    configure the pod network without NetworkPolicy support. In these
+    cases, the API will still be present, but it will have no effect.)
+
+  * There are many [implementations of the Gateway
+    API](https://gateway-api.sigs.k8s.io/implementations/), some of
+    which are specific to particular cloud environments, some more
+    focused on "bare metal" environments, and others more generic.
+
+## {{% heading "whatsnext" %}}
 
 The [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) tutorial lets you learn about Services and Kubernetes networking with a hands-on example.
 

content/en/docs/concepts/services-networking/dns-pod-service.md

@@ -191,8 +191,7 @@ An {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} can spec
 the DNS hostname for any endpoint addresses, along with its IP.
 
 {{< note >}}
-Because A and AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
+A and AAAA records are not created for Pod names since `hostname` is missing for the Pod. A Pod with no `hostname` but with `subdomain` will only create the
-record to be created. A Pod with no `hostname` but with `subdomain` will only create the
 A or AAAA record for the headless Service (`busybox-subdomain.my-namespace.svc.cluster-domain.example`),
 pointing to the Pods' IP addresses. Also, the Pod needs to be ready in order to have a
 record unless `publishNotReadyAddresses=True` is set on the Service.

content/en/docs/concepts/services-networking/ingress.md

@@ -87,7 +87,10 @@ A minimal Ingress resource example:
 An Ingress needs `apiVersion`, `kind`, `metadata` and `spec` fields.
 The name of an Ingress object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
+For general information about working with config files, see
+[deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/),
+[configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[managing resources](/docs/concepts/workloads/management/).
 Ingress frequently uses annotations to configure some options depending on the Ingress controller, an example of which
 is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md).
 Different [Ingress controllers](/docs/concepts/services-networking/ingress-controllers) support different annotations.

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

@@ -46,12 +46,15 @@ different purposes:
   [downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
   [secret](/docs/concepts/storage/volumes/#secret): inject different
   kinds of Kubernetes data into a Pod
+- [image](/docs/concepts/storage/volumes/#image): allows mounting container image files or artifacts,
+  directly to a Pod.
 - [CSI ephemeral volumes](#csi-ephemeral-volumes):
   similar to the previous volume kinds, but provided by special {{< glossary_tooltip text="CSI" term_id="csi" >}} drivers
   which specifically [support this feature](https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html)
 - [generic ephemeral volumes](#generic-ephemeral-volumes), which
   can be provided by all storage drivers that also support persistent volumes
 
+
 `emptyDir`, `configMap`, `downwardAPI`, `secret` are provided as
 [local ephemeral
 storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).

content/en/docs/concepts/storage/storage-classes.md

@@ -296,6 +296,27 @@ allowedTopologies:
     values:
     - us-east-2c
 ```
+### AWS EFS
+
+To configure AWS EFS storage, you can use the out-of-tree [AWS_EFS_CSI_DRIVER](https://github.com/kubernetes-sigs/aws-efs-csi-driver).
+
+```yaml
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: efs-sc
+provisioner: efs.csi.aws.com
+parameters:
+  provisioningMode: efs-ap
+  fileSystemId: fs-92107410
+  directoryPerms: "700"
+```
+
+- `provisioningMode`: The type of volume to be provisioned by Amazon EFS. Currently, only access point based provisioning is supported (`efs-ap`).
+- `fileSystemId`: The file system under which the access point is created.
+- `directoryPerms`: The directory permissions of the root directory created by the access point.
+
+For more details, refer to the [AWS_EFS_CSI_Driver Dynamic Provisioning](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) documentation.
 
 ### NFS
 

content/en/docs/concepts/storage/volume-attributes-classes.md

@@ -23,13 +23,16 @@ Kubernetes itself is un-opinionated about what these classes represent.
 This is a beta feature and disabled by default.
 
 If you want to test the feature whilst it's beta, you need to enable the `VolumeAttributesClass`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-controller-manager and the kube-apiserver. You use the `--feature-gates` command line argument:
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-controller-manager, kube-scheduler,
+and the kube-apiserver. You use the `--feature-gates` command line argument:
 
 ```
 --feature-gates="...,VolumeAttributesClass=true"
 ```
 
-You will also have to enable the `storage.k8s.io/v1beta1` API group through the `kube-apiserver` [runtime-config](https://kubernetes.io/docs/tasks/administer-cluster/enable-disable-api/). You use the following command line argument: 
+You will also have to enable the `storage.k8s.io/v1beta1` API group through the
+`kube-apiserver` [runtime-config](https://kubernetes.io/docs/tasks/administer-cluster/enable-disable-api/).
+You use the following command line argument:
 
 ```
 --runtime-config=storage.k8s.io/v1beta1=true
@@ -49,7 +52,6 @@ The name of a VolumeAttributesClass object is significant and is how users can r
 Administrators set the name and other parameters of a class when first creating VolumeAttributesClass objects.
 While the name of a VolumeAttributesClass object in a `PersistentVolumeClaim` is mutable, the parameters in an existing class are immutable.
 
-
 ```yaml
 apiVersion: storage.k8s.io/v1beta1
 kind: VolumeAttributesClass
@@ -61,24 +63,27 @@ parameters:
   provisioned-throughput: "50" 
 ```
 
-
 ### Provisioner
 
-Each VolumeAttributesClass has a provisioner that determines what volume plugin is used for provisioning PVs. The field `driverName` must be specified. 
+Each VolumeAttributesClass has a provisioner that determines what volume plugin is used for
+provisioning PVs. The field `driverName` must be specified.
 
-The feature support for VolumeAttributesClass is implemented in [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
+The feature support for VolumeAttributesClass is implemented in
+[kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
 
-You are not restricted to specifying the [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner). You can also run and specify external provisioners,
+You are not restricted to specifying the [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
+You can also run and specify external provisioners,
 which are independent programs that follow a specification defined by Kubernetes.
 Authors of external provisioners have full discretion over where their code lives, how
-the provisioner is shipped, how it needs to be run, what volume plugin it uses, etc. 
+the provisioner is shipped, how it needs to be run, what volume plugin it uses, etc.
-
 
 ### Resizer
 
-Each VolumeAttributesClass has a resizer that determines what volume plugin is used for modifying PVs. The field `driverName` must be specified. 
+Each VolumeAttributesClass has a resizer that determines what volume plugin is used
+for modifying PVs. The field `driverName` must be specified.
 
-The modifying volume feature support for VolumeAttributesClass is implemented in [kubernetes-csi/external-resizer](https://github.com/kubernetes-csi/external-resizer).
+The modifying volume feature support for VolumeAttributesClass is implemented in
+[kubernetes-csi/external-resizer](https://github.com/kubernetes-csi/external-resizer).
 
 For example, an existing PersistentVolumeClaim is using a VolumeAttributesClass named silver:
 
@@ -95,7 +100,6 @@ spec:
 
 A new VolumeAttributesClass gold is available in the cluster:
 
-
 ```yaml
 apiVersion: storage.k8s.io/v1beta1
 kind: VolumeAttributesClass
@@ -107,10 +111,8 @@ parameters:
   throughput: "60"
 ```
 
-
 The end user can update the PVC with the new VolumeAttributesClass gold and apply:
 
-
 ```yaml
 apiVersion: v1
 kind: PersistentVolumeClaim
@@ -122,15 +124,14 @@ spec:
   …
 ```
 
-
 ## Parameters
 
 VolumeAttributeClasses have parameters that describe volumes belonging to them. Different parameters may be accepted
 depending on the provisioner or the resizer. For example, the value `4000`, for the parameter `iops`,
-and the parameter `throughput` are specific to GCE PD. 
+and the parameter `throughput` are specific to GCE PD.
 When a parameter is omitted, the default is used at volume provisioning.
-If a user apply the PVC with a different VolumeAttributesClass with omitted parameters, the default value of
+If a user applies the PVC with a different VolumeAttributesClass with omitted parameters, the default value of
-the parameters may be used depends on the CSI driver implementation.
+the parameters may be used depending on the CSI driver implementation.
 Please refer to the related CSI driver documentation for more details.
 
 There can be at most 512 parameters defined for a VolumeAttributesClass.

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

@@ -865,7 +865,7 @@ are redirected to the `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" t
 
 [vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)
 must be installed on the cluster. You can find additional advice on how to migrate in-tree `vsphereVolume` in VMware's documentation page
-[Migrating In-Tree vSphere Volumes to vSphere Container Storage lug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html).
+[Migrating In-Tree vSphere Volumes to vSphere Container Storage Plug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html).
 If vSphere CSI Driver is not installed volume operations can not be performed on the PV created with the in-tree `vsphereVolume` type.
 
 You must run vSphere 7.0u2 or later in order to migrate to the vSphere CSI driver.
@@ -1197,6 +1197,13 @@ Users of FlexVolume should move their workloads to use the equivalent CSI Driver
 
 ## Mount propagation
 
+  {{< caution >}}
+  Mount propagation is a low-level feature that does not work consistently on all
+  volume types. It is recommended to use only with `hostPath` or in-memory `emptyDir`
+  volumes. See [this discussion](https://github.com/kubernetes/kubernetes/issues/95049)
+  for more context. 
+  {{< /caution >}}
+
 Mount propagation allows for sharing volumes mounted by a container to
 other containers in the same pod, or even to other pods on the same node.
 

content/en/docs/concepts/windows/intro.md

@@ -368,7 +368,7 @@ Depending on the requirements for your workload these values may need to be adju
 Refer to
 [Hardware requirements for Windows Server Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements)
 for the most up-to-date information on minimum hardware requirements. For guidance on deciding on resources for
-production worker nodes refer to [Production worker nodes Kubernetes documentation](https://kubernetes.io/docs/setup/production-environment/#production-worker-nodes).
+production worker nodes refer to [Production worker nodes Kubernetes documentation](/docs/setup/production-environment/#production-worker-nodes).
 
 To optimize system resources, if a graphical user interface is not required,
 it may be preferable to use a Windows Server OS installation that excludes
@@ -432,4 +432,4 @@ For a detailed explanation of Windows distribution channels see the
 
 Information on the different Windows Server servicing channels
 including their support models can be found at
-[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).
+[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).

content/en/docs/concepts/workloads/controllers/cron-jobs.md

@@ -65,7 +65,7 @@ The `.spec.schedule` field is required. The value of that field follows the [Cro
 # * * * * *
 ```
 
-For example, `0 0 13 * 5` states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight.
+For example, `0 3 * * 1` means this task is scheduled to run weekly on a Monday at 3 AM.
 
 The format also includes extended "Vixie cron" step values. As explained in the
 [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):

content/en/docs/concepts/workloads/controllers/deployment.md

@@ -813,9 +813,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
   ```
   deployment.apps/nginx-deployment resumed
   ```
-* Watch the status of the rollout until it's done.
+* {{< glossary_tooltip text="Watch" term_id="watch" >}} the status of the rollout until it's done.
   ```shell
-  kubectl get rs -w
+  kubectl get rs --watch
   ```
 
   The output is similar to this:
@@ -1083,7 +1083,7 @@ thus that Deployment will not be able to roll back.
 
 If you want to roll out releases to a subset of users or servers using the Deployment, you
 can create multiple Deployments, one for each release, following the canary pattern described in
-[managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
+[managing resources](/docs/concepts/workloads/management/#canary-deployments).
 
 ## Writing a Deployment Spec
 

content/en/docs/concepts/workloads/controllers/job.md

@@ -1078,7 +1078,7 @@ and `.spec.completions` together such that `.spec.parallelism == .spec.completio
 When scaling down, Kubernetes removes the Pods with higher indexes.
 
 Use cases for elastic Indexed Jobs include batch workloads which require 
-scaling an indexed Job, such as MPI, Horovord, Ray, and PyTorch training jobs.
+scaling an indexed Job, such as MPI, Horovod, Ray, and PyTorch training jobs.
 
 ### Delayed creation of replacement pods {#pod-replacement-policy}
 

content/en/docs/concepts/workloads/pods/_index.md

@@ -316,7 +316,7 @@ Pods, the kubelet directly supervises each static Pod (and restarts it if it fai
 
 Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
 The main use for static Pods is to run a self-hosted control plane: in other words,
-using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
+using the kubelet to supervise the individual [control plane components](/docs/concepts/architecture/#control-plane-components).
 
 The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
 on the Kubernetes API server for each static Pod.

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

@@ -111,8 +111,20 @@ Value       | Description
 `Unknown`   | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
 
 {{< note >}}
-When a Pod is being deleted, it is shown as `Terminating` by some kubectl commands.
+
-This `Terminating` status is not one of the Pod phases.
+When a pod is failing to start repeatedly, `CrashLoopBackOff` may appear in the `Status` field of some kubectl commands. Similarly, when a pod is being deleted, `Terminating` may appear in the `Status` field of some kubectl commands. 
+
+Make sure not to confuse _Status_, a kubectl display field for user intuition, with the pod's `phase`.
+Pod phase is an explicit part of the Kubernetes data model and of the
+[Pod API](/docs/reference/kubernetes-api/workload-resources/pod-v1/). 
+
+```
+  NAMESPACE               NAME               READY   STATUS             RESTARTS   AGE
+  alessandras-namespace   alessandras-pod    0/1     CrashLoopBackOff   200        2d9h
+```
+
+---
+
 A Pod is granted a term to terminate gracefully, which defaults to 30 seconds.
 You can use the flag `--force` to [terminate a Pod by force](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced).
 {{< /note >}}

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

@@ -143,6 +143,7 @@ request and limit, the same as the scheduler.
 
 ## {{% heading "whatsnext" %}}
 
+* Learn how to [Adopt Sidecar Containers](/docs/tutorials/configuration/pod-sidecar-containers/)
 * Read a blog post on [native sidecar containers](/blog/2023/08/25/native-sidecar-containers/).
 * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container).
 * Learn about the [types of probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe.

content/en/docs/contribute/new-content/blogs-case-studies.md

@@ -157,6 +157,10 @@ To submit a blog post follow these directions:
     title: "Your Title Here"
     date: YYYY-MM-DD
     slug: text-for-URL-link-here-no-spaces
+    author: >
+      Author-1 (Affiliation),
+      Author-2 (Affiliation),
+      Author-3 (Affiliation)
     ---
     ```
 
@@ -195,7 +199,7 @@ To mirror a blog post from the [Kubernetes contributor blog](https://www.kuberne
 
 - Keep the blog content the same. If there are changes, they should be made to the original article first, and then to the mirrored article.
 - The mirrored blog should have a `canonicalUrl`, that is, essentially the url of the original blog after it has been published.
-- [Kubernetes contributor blogs](https://kubernetes.dev/blog) have their authors mentioned in the YAML header, while the Kubernetes blog posts mention authors in the blog content itself. This should be changed when mirroring the content.
+- Same as [Kubernetes contributor blogs](https://kubernetes.dev/blog), Kubernetes blog posts also mention authors in the YAML header as per the new guidelines. This should be ensured.
 - Publication dates stay the same as the original blog.
 
 All of the other guidelines and expectations detailed above apply as well.

content/en/docs/contribute/new-content/open-a-pr.md

@@ -213,7 +213,7 @@ Figure 2. Working from a local fork to make your changes.
 
 ### Create a branch
 
-1. Decide which branch base to your work on:
+1. Decide which branch to base your work on:
 
    - For improvements to existing content, use `upstream/main`.
    - For new content about existing features, use `upstream/main`.

content/en/docs/contribute/participate/pr-wranglers.md

@@ -130,10 +130,6 @@ The program was introduced to help new contributors understand the PR wrangling
   [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers)
   to see the PR wrangling schedule for this year and sign up.
 
-- Kubernetes org members can edit the
-  [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers)
-  and sign up to shadow an existing PR Wrangler for a week.
-
 - Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs)
   for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to
   Brad Topol (`@bradtopol`) or one of the

content/en/docs/reference/access-authn-authz/bootstrap-tokens.md

@@ -116,7 +116,7 @@ authenticate to the API server as a bearer token.
 
 The `expiration` field controls the expiry of the token. Expired tokens are
 rejected when used for authentication and ignored during ConfigMap signing.
-The expiry value is encoded as an absolute UTC time using RFC3339. Enable the
+The expiry value is encoded as an absolute UTC time using [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339). Enable the
 `tokencleaner` controller to automatically delete expired tokens.
 
 ## Token Management with kubeadm

content/en/docs/reference/command-line-tools-reference/feature-gates/RemoveSelfLink.md

@@ -1,5 +1,4 @@
 ---
-removed: true
 title: RemoveSelfLink
 content_type: feature_gate
 _build:
@@ -19,6 +18,8 @@ stages:
     defaultValue: true
     fromVersion: "1.24"  
     toVersion: "1.29"
+
+removed: true
 ---
 Sets the `.metadata.selfLink` field to blank (empty string) for all
 objects and collections. This field has been deprecated since the Kubernetes v1.16

content/en/docs/reference/config-api/apiserver-admission.v1.md

@@ -152,7 +152,7 @@ requested. e.g. a patch can result in either a CREATE or UPDATE Operation.</p>
 </td>
 </tr>
 <tr><td><code>userInfo</code> <B>[Required]</B><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
 </td>
 <td>
    <p>UserInfo is information about the requesting user</p>
@@ -226,7 +226,7 @@ This must be copied over from the corresponding AdmissionRequest.</p>
 </td>
 </tr>
 <tr><td><code>status</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#status-v1-meta"><code>meta/v1.Status</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#status-v1-meta"><code>meta/v1.Status</code></a>
 </td>
 <td>
    <p>Result contains extra details into why an admission request was denied.

content/en/docs/reference/config-api/apiserver-audit.v1.md

@@ -71,14 +71,14 @@ For non-resource requests, this is the lower-cased HTTP method.</p>
 </td>
 </tr>
 <tr><td><code>user</code> <B>[Required]</B><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
 </td>
 <td>
    <p>Authenticated user information.</p>
 </td>
 </tr>
 <tr><td><code>impersonatedUser</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
 </td>
 <td>
    <p>Impersonated user information.</p>
@@ -116,7 +116,7 @@ Does not apply for List-type requests, or non-resource requests.</p>
 </td>
 </tr>
 <tr><td><code>responseStatus</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#status-v1-meta"><code>meta/v1.Status</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#status-v1-meta"><code>meta/v1.Status</code></a>
 </td>
 <td>
    <p>The response status, populated even when the ResponseObject is not a Status type.
@@ -144,14 +144,14 @@ at Response Level.</p>
 </td>
 </tr>
 <tr><td><code>requestReceivedTimestamp</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
 </td>
 <td>
    <p>Time the request reached the apiserver.</p>
 </td>
 </tr>
 <tr><td><code>stageTimestamp</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
 </td>
 <td>
    <p>Time the request reached current audit stage.</p>
@@ -188,7 +188,7 @@ should be short. Annotations are included in the Metadata level.</p>
     
   
 <tr><td><code>metadata</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
 </td>
 <td>
    <span class="text-muted">No description provided.</span></td>
@@ -223,7 +223,7 @@ categories are logged.</p>
     
   
 <tr><td><code>metadata</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
 </td>
 <td>
    <p>ObjectMeta is included for interoperability with API infrastructure.</p>
@@ -278,7 +278,7 @@ in a rule will override the global default.</p>
     
   
 <tr><td><code>metadata</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
 </td>
 <td>
    <span class="text-muted">No description provided.</span></td>

content/en/docs/reference/config-api/apiserver-config.v1alpha1.md

@@ -119,10 +119,17 @@ JWT authenticator will attempt to cryptographically validate the token.</p>
 &quot;iss&quot;: &quot;https://issuer.example.com&quot;,
 &quot;aud&quot;: [&quot;audience&quot;],
 &quot;exp&quot;: 1234567890,
-&quot;&lt;username claim&gt;&quot;: &quot;username&quot;
+&quot;<!-- raw HTML omitted -->&quot;: &quot;username&quot;
 }</p>
 </td>
 </tr>
+<tr><td><code>anonymous</code> <B>[Required]</B><br/>
+<a href="#apiserver-k8s-io-v1alpha1-AnonymousAuthConfig"><code>AnonymousAuthConfig</code></a>
+</td>
+<td>
+   <p>If present --anonymous-auth must not be set</p>
+</td>
+</tr>
 </tbody>
 </table>
 
@@ -245,6 +252,66 @@ configuration. If present, it will be used instead of the path to the configurat
 </tbody>
 </table>
 
+## `AnonymousAuthCondition`     {#apiserver-k8s-io-v1alpha1-AnonymousAuthCondition}
+    
+
+**Appears in:**
+
+- [AnonymousAuthConfig](#apiserver-k8s-io-v1alpha1-AnonymousAuthConfig)
+
+
+<p>AnonymousAuthCondition describes the condition under which anonymous auth
+should be enabled.</p>
+
+
+<table class="table">
+<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
+<tbody>
+    
+  
+<tr><td><code>path</code> <B>[Required]</B><br/>
+<code>string</code>
+</td>
+<td>
+   <p>Path for which anonymous auth is enabled.</p>
+</td>
+</tr>
+</tbody>
+</table>
+
+## `AnonymousAuthConfig`     {#apiserver-k8s-io-v1alpha1-AnonymousAuthConfig}
+    
+
+**Appears in:**
+
+- [AuthenticationConfiguration](#apiserver-k8s-io-v1alpha1-AuthenticationConfiguration)
+
+
+<p>AnonymousAuthConfig provides the configuration for the anonymous authenticator.</p>
+
+
+<table class="table">
+<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
+<tbody>
+    
+  
+<tr><td><code>enabled</code> <B>[Required]</B><br/>
+<code>bool</code>
+</td>
+<td>
+   <span class="text-muted">No description provided.</span></td>
+</tr>
+<tr><td><code>conditions</code> <B>[Required]</B><br/>
+<a href="#apiserver-k8s-io-v1alpha1-AnonymousAuthCondition"><code>[]AnonymousAuthCondition</code></a>
+</td>
+<td>
+   <p>If set, anonymous auth is only allowed if the request meets one of the
+conditions.</p>
+</td>
+</tr>
+</tbody>
+</table>
+
 ## `AudienceMatchPolicyType`     {#apiserver-k8s-io-v1alpha1-AudienceMatchPolicyType}
     
 (Alias of `string`)
@@ -331,7 +398,7 @@ The claim's value must be a singular string.
 Same as the --oidc-username-claim and --oidc-username-prefix flags.
 If username.expression is set, the expression must produce a string value.
 If username.expression uses 'claims.email', then 'claims.email_verified' must be used in
-username.expression or extra[&ast;].valueExpression or claimValidationRules[&ast;].expression.
+username.expression or extra[<em>].valueExpression or claimValidationRules[</em>].expression.
 An example claim validation rule expression that matches the validation automatically
 applied when username.claim is set to 'email' is 'claims.?email_verified.orValue(true)'.</p>
 <p>In the flag based approach, the --oidc-username-claim and --oidc-username-prefix are optional. If --oidc-username-claim is not set,
@@ -341,8 +408,8 @@ For prefix:
 (1) --oidc-username-prefix=&quot;-&quot;, no prefix was added to the username. For the same behavior using authentication config,
 set username.prefix=&quot;&quot;
 (2) --oidc-username-prefix=&quot;&quot; and  --oidc-username-claim != &quot;email&quot;, prefix was &quot;&lt;value of --oidc-issuer-url&gt;#&quot;. For the same
-behavior using authentication config, set username.prefix=&quot;&lt;value of issuer.url&gt;#&quot;
+behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->#&quot;
-(3) --oidc-username-prefix=&quot;&lt;value&gt;&quot;. For the same behavior using authentication config, set username.prefix=&quot;&lt;value&gt;&quot;</p>
+(3) --oidc-username-prefix=&quot;<!-- raw HTML omitted -->&quot;. For the same behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->&quot;</p>
 </td>
 </tr>
 <tr><td><code>groups</code><br/>
@@ -1202,4 +1269,4 @@ the contents would be converted to the v1 version before evaluating the CEL expr
 </tr>
 </tbody>
 </table>
-  
+  

content/en/docs/reference/config-api/apiserver-config.v1beta1.md

@@ -95,10 +95,17 @@ JWT authenticator will attempt to cryptographically validate the token.</p>
 &quot;iss&quot;: &quot;https://issuer.example.com&quot;,
 &quot;aud&quot;: [&quot;audience&quot;],
 &quot;exp&quot;: 1234567890,
-&quot;&lt;username claim&gt;&quot;: &quot;username&quot;
+&quot;<!-- raw HTML omitted -->&quot;: &quot;username&quot;
 }</p>
 </td>
 </tr>
+<tr><td><code>anonymous</code> <B>[Required]</B><br/>
+<a href="#apiserver-k8s-io-v1beta1-AnonymousAuthConfig"><code>AnonymousAuthConfig</code></a>
+</td>
+<td>
+   <p>If present --anonymous-auth must not be set</p>
+</td>
+</tr>
 </tbody>
 </table>
 
@@ -178,6 +185,66 @@ Must be at least one.</p>
 </tbody>
 </table>
 
+## `AnonymousAuthCondition`     {#apiserver-k8s-io-v1beta1-AnonymousAuthCondition}
+    
+
+**Appears in:**
+
+- [AnonymousAuthConfig](#apiserver-k8s-io-v1beta1-AnonymousAuthConfig)
+
+
+<p>AnonymousAuthCondition describes the condition under which anonymous auth
+should be enabled.</p>
+
+
+<table class="table">
+<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
+<tbody>
+    
+  
+<tr><td><code>path</code> <B>[Required]</B><br/>
+<code>string</code>
+</td>
+<td>
+   <p>Path for which anonymous auth is enabled.</p>
+</td>
+</tr>
+</tbody>
+</table>
+
+## `AnonymousAuthConfig`     {#apiserver-k8s-io-v1beta1-AnonymousAuthConfig}
+    
+
+**Appears in:**
+
+- [AuthenticationConfiguration](#apiserver-k8s-io-v1beta1-AuthenticationConfiguration)
+
+
+<p>AnonymousAuthConfig provides the configuration for the anonymous authenticator.</p>
+
+
+<table class="table">
+<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
+<tbody>
+    
+  
+<tr><td><code>enabled</code> <B>[Required]</B><br/>
+<code>bool</code>
+</td>
+<td>
+   <span class="text-muted">No description provided.</span></td>
+</tr>
+<tr><td><code>conditions</code> <B>[Required]</B><br/>
+<a href="#apiserver-k8s-io-v1beta1-AnonymousAuthCondition"><code>[]AnonymousAuthCondition</code></a>
+</td>
+<td>
+   <p>If set, anonymous auth is only allowed if the request meets one of the
+conditions.</p>
+</td>
+</tr>
+</tbody>
+</table>
+
 ## `AudienceMatchPolicyType`     {#apiserver-k8s-io-v1beta1-AudienceMatchPolicyType}
     
 (Alias of `string`)
@@ -264,7 +331,7 @@ The claim's value must be a singular string.
 Same as the --oidc-username-claim and --oidc-username-prefix flags.
 If username.expression is set, the expression must produce a string value.
 If username.expression uses 'claims.email', then 'claims.email_verified' must be used in
-username.expression or extra[&ast;].valueExpression or claimValidationRules[&ast;].expression.
+username.expression or extra[<em>].valueExpression or claimValidationRules[</em>].expression.
 An example claim validation rule expression that matches the validation automatically
 applied when username.claim is set to 'email' is 'claims.?email_verified.orValue(true)'.</p>
 <p>In the flag based approach, the --oidc-username-claim and --oidc-username-prefix are optional. If --oidc-username-claim is not set,
@@ -274,8 +341,8 @@ For prefix:
 (1) --oidc-username-prefix=&quot;-&quot;, no prefix was added to the username. For the same behavior using authentication config,
 set username.prefix=&quot;&quot;
 (2) --oidc-username-prefix=&quot;&quot; and  --oidc-username-claim != &quot;email&quot;, prefix was &quot;&lt;value of --oidc-issuer-url&gt;#&quot;. For the same
-behavior using authentication config, set username.prefix=&quot;&lt;value of issuer.url&gt;#&quot;
+behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->#&quot;
-(3) --oidc-username-prefix=&quot;&lt;value&gt;&quot;. For the same behavior using authentication config, set username.prefix=&quot;&lt;value&gt;&quot;</p>
+(3) --oidc-username-prefix=&quot;<!-- raw HTML omitted -->&quot;. For the same behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->&quot;</p>
 </td>
 </tr>
 <tr><td><code>groups</code><br/>
@@ -1135,4 +1202,4 @@ the contents would be converted to the v1 version before evaluating the CEL expr
 </tr>
 </tbody>
 </table>
-  
+  

content/en/docs/reference/config-api/client-authentication.v1.md

@@ -205,7 +205,7 @@ itself should at least be protected via file permissions.</p>
     
   
 <tr><td><code>expirationTimestamp</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#time-v1-meta"><code>meta/v1.Time</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#time-v1-meta"><code>meta/v1.Time</code></a>
 </td>
 <td>
    <p>ExpirationTimestamp indicates a time when the provided credentials expire.</p>

content/en/docs/reference/config-api/client-authentication.v1beta1.md

@@ -205,7 +205,7 @@ itself should at least be protected via file permissions.</p>
     
   
 <tr><td><code>expirationTimestamp</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#time-v1-meta"><code>meta/v1.Time</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#time-v1-meta"><code>meta/v1.Time</code></a>
 </td>
 <td>
    <p>ExpirationTimestamp indicates a time when the provided credentials expire.</p>

content/en/docs/reference/config-api/imagepolicy.v1alpha1.md

@@ -28,7 +28,7 @@ auto_generated: true
     
   
 <tr><td><code>metadata</code><br/>
-<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
 </td>
 <td>
    <p>Standard object's metadata.

content/en/docs/reference/config-api/kube-controller-manager-config.v1alpha1.md

@@ -1256,13 +1256,6 @@ Larger number = more responsive HPA processing, but more CPU (and network) load.
 pods in horizontal pod autoscaler.</p>
 </td>
 </tr>
-<tr><td><code>HorizontalPodAutoscalerUpscaleForbiddenWindow</code> <B>[Required]</B><br/>
-<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
-</td>
-<td>
-   <p>HorizontalPodAutoscalerUpscaleForbiddenWindow is a period after which next upscale allowed.</p>
-</td>
-</tr>
 <tr><td><code>HorizontalPodAutoscalerDownscaleStabilizationWindow</code> <B>[Required]</B><br/>
 <a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
 </td>
@@ -1271,13 +1264,6 @@ pods in horizontal pod autoscaler.</p>
 backwards and not scale down below any recommendation it made during that period.</p>
 </td>
 </tr>
-<tr><td><code>HorizontalPodAutoscalerDownscaleForbiddenWindow</code> <B>[Required]</B><br/>
-<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
-</td>
-<td>
-   <p>HorizontalPodAutoscalerDownscaleForbiddenWindow is a period after which next downscale allowed.</p>
-</td>
-</tr>
 <tr><td><code>HorizontalPodAutoscalerTolerance</code> <B>[Required]</B><br/>
 <code>float64</code>
 </td>
@@ -1556,22 +1542,6 @@ and persistent volume claims.</p>
    <p>volumeConfiguration holds configuration for volume related features.</p>
 </td>
 </tr>
-<tr><td><code>VolumeHostCIDRDenylist</code> <B>[Required]</B><br/>
-<code>[]string</code>
-</td>
-<td>
-   <p>DEPRECATED: VolumeHostCIDRDenylist is a list of CIDRs that should not be reachable by the
-controller from plugins.</p>
-</td>
-</tr>
-<tr><td><code>VolumeHostAllowLocalLoopback</code> <B>[Required]</B><br/>
-<code>bool</code>
-</td>
-<td>
-   <p>DEPRECATED: VolumeHostAllowLocalLoopback indicates if local loopback hosts (127.0.0.1, etc)
-should be allowed from plugins.</p>
-</td>
-</tr>
 </tbody>
 </table>