Merge branch 'kubernetes:main' into hi-12

Author: Vikash-8090-Yadav

content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md

@@ -12,7 +12,7 @@ In Kubernetes, features follow a defined
 First, as the twinkle of an eye in an interested developer. Maybe, then,
 sketched in online discussions, drawn on the online equivalent of a cafe
 napkin. This rough work typically becomes a
-[Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/0001-kubernetes-enhancement-proposal-process.md#kubernetes-enhancement-proposal-process) (KEP), and
+[Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md#kubernetes-enhancement-proposal-process) (KEP), and
 from there it usually turns into code.
 
 For Kubernetes v1.20 and onwards, we're focusing on helping that code

content/en/blog/_posts/2023-08-28-a-new-alpha-mechanism-for-safer-cluster-upgrades.md

@@ -0,0 +1,51 @@
+---
+layout: blog
+title: "Kubernetes 1.28: A New (alpha) Mechanism For Safer Cluster Upgrades"
+date: 2023-08-28
+slug: kubernetes-1-28-feature-mixed-version-proxy-alpha
+---
+
+**Author:** Richa Banker (Google)
+
+This blog describes the _mixed version proxy_, a new alpha feature in Kubernetes 1.28. The
+mixed version proxy enables an HTTP request for a resource to be served by the correct API server
+in cases where there are multiple API servers at varied versions in a cluster. For example,
+this is useful during a cluster upgrade, or when you're rolling out the runtime configuration of
+the cluster's control plane.
+
+## What problem does this solve?
+When a cluster undergoes an upgrade, the kube-apiservers existing at different versions in that scenario can serve different sets (groups, versions, resources) of built-in resources. A resource request made in this scenario may be served by any of the available apiservers, potentially resulting in the request ending up at an apiserver that may not be aware of the requested resource; consequently it being served a 404 not found error which is incorrect. Furthermore, incorrect serving of the 404 errors can lead to serious consequences such as namespace deletion being blocked incorrectly or objects being garbage collected mistakenly.
+
+## How do we solve the problem?
+
+{{< figure src="/images/blog/2023-08-28-a-new-alpha-mechanism-for-safer-cluster-upgrades/mvp-flow-diagram.svg" class="diagram-large" >}}
+
+The new feature “Mixed Version Proxy” provides the kube-apiserver with the capability to proxy a request to a peer kube-apiserver which is aware of the requested resource and hence can serve the request. To do this, a new filter has been added to the handler chain in the API server's aggregation layer.
+
+1. The new filter in the handler chain checks if the request is for a group/version/resource that the apiserver doesn't know about (using the existing [StorageVersion API](https://github.com/kubernetes/kubernetes/blob/release-1.28/pkg/apis/apiserverinternal/types.go#L25-L37)). If so, it proxies the request to one of the apiservers that is listed in the ServerStorageVersion object. If the identified peer apiserver fails to respond (due to reasons like network connectivity, race between the request being received and the controller registering the apiserver-resource info in ServerStorageVersion object), then error 503("Service Unavailable") is served.
+2. To prevent indefinite proxying of the request, a (new for v1.28) HTTP header `X-Kubernetes-APIServer-Rerouted: true` is added to the original request once it is determined that the request cannot be served by the original API server. Setting that to true marks that the original API server couldn't handle the request and it should therefore be proxied. If a destination peer API server sees this header, it never proxies the request further.
+3. To set the network location of a kube-apiserver that peers will use to proxy requests, the value passed in `--advertise-address` or (when `--advertise-address` is unspecified) the `--bind-address` flag is used. For users with network configurations that would not allow communication between peer kube-apiservers using the addresses specified in these flags, there is an option to pass in the correct peer address as `--peer-advertise-ip` and `--peer-advertise-port` flags that are introduced in this feature.
+
+## How do I enable this feature?
+Following are the required steps to enable the feature:
+
+* Download the [latest Kubernetes project](/releases/download/) (version `v1.28.0` or later)  
+* Switch on the feature gate with the command line flag `--feature-gates=UnknownVersionInteroperabilityProxy=true` on the kube-apiservers
+* Pass the CA bundle that will be used by source kube-apiserver to authenticate destination kube-apiserver's serving certs using the flag `--peer-ca-file` on the kube-apiservers. Note: this is a required flag for this feature to work. There is no default value enabled for this flag.
+* Pass the correct ip and port of the local kube-apiserver that will be used by peers to connect to this kube-apiserver while proxying a request. Use the flags `--peer-advertise-ip` and `peer-advertise-port` to the kube-apiservers upon startup. If unset, the value passed to either `--advertise-address` or `--bind-address` is used. If those too, are unset, the host's default interface will be used.
+
+## What’s missing?
+Currently we only proxy resource requests to a peer kube-apiserver when its determined to do so. Next we need to address how to work discovery requests in such scenarios. Right now we are planning to have the following capabilities for beta
+
+* Merged discovery across all kube-apiservers
+* Use an egress dialer for network connections made to peer kube-apiservers
+
+## How can I learn more?
+
+- Read the [Mixed Version Proxy documentation](/docs/concepts/architecture/mixed-version-proxy)
+- Read [KEP-4020: Unknown Version Interoperability Proxy](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/4020-unknown-version-interoperability-proxy)
+
+## How can I get involved?
+Reach us on [Slack](https://slack.k8s.io/): [#sig-api-machinery](https://kubernetes.slack.com/messages/sig-api-machinery), or through the [mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-api-machinery). 
+
+Huge thanks to the contributors that have helped in the design, implementation, and review of this feature: Daniel Smith, Han Kang, Joe Betz, Jordan Liggit, Antonio Ojea, David Eads and Ben Luddy!

content/en/blog/_posts/2023-08-29-Gateway-API-v080.md

@@ -0,0 +1,195 @@
+---
+layout: blog
+title: "Gateway API v0.8.0: Introducing Service Mesh Support"
+date: 2023-08-29T10:00:00-08:00
+slug: gateway-api-v0-8
+---
+
+***Authors:*** Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google)
+
+We are thrilled to announce the v0.8.0 release of Gateway API! With this
+release, Gateway API support for service mesh has reached [Experimental
+status][status]. We look forward to your feedback!
+
+We're especially delighted to announce that Kuma 2.3+, Linkerd 2.14+, and Istio
+1.16+ are all fully-conformant implementations of Gateway API service mesh
+support.
+
+## Service mesh support in Gateway API
+
+While the initial focus of Gateway API was always ingress (north-south)
+traffic, it was clear almost from the beginning that the same basic routing
+concepts should also be applicable to service mesh (east-west) traffic. In
+2022, the Gateway API subproject started the [GAMMA initiative][gamma], a
+dedicated vendor-neutral workstream, specifically to examine how best to fit
+service mesh support into the framework of the Gateway API resources, without
+requiring users of Gateway API to relearn everything they understand about the
+API.
+
+Over the last year, GAMMA has dug deeply into the challenges and possible
+solutions around using Gateway API for service mesh. The end result is a small
+number of [enhancement proposals][geps] that subsume many hours of thought and
+debate, and provide a minimum viable path to allow Gateway API to be used for
+service mesh.
+
+### How will mesh routing work when using Gateway API?
+
+You can find all the details in the [Gateway API Mesh routing
+documentation][mesh-routing] and [GEP-1426], but the short version for Gateway
+API v0.8.0 is that an HTTPRoute can now have a `parentRef` that is a Service,
+rather than just a Gateway. We anticipate future GEPs in this area as we gain
+more experience with service mesh use cases -- binding to a Service makes it
+possible to use the Gateway API with a service mesh, but there are several
+interesting use cases that remain difficult to cover.
+
+As an example, you might use an HTTPRoute to do an A-B test in the mesh as
+follows:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: bar-route
+spec:
+  parentRefs:
+  - group: ""
+    kind: Service
+    name: demo-app
+    port: 5000
+  rules:
+  - matches:
+    - headers:
+      - type: Exact
+        name: env
+        value: v1
+    backendRefs:
+    - name: demo-app-v1
+      port: 5000
+  - backendRefs:
+    - name: demo-app-v2
+      port: 5000
+```
+
+Any request to port 5000 of the `demo-app` Service that has the header `env:
+v1` will be routed to `demo-app-v1`, while any request without that header
+will be routed to `demo-app-v2` -- and since this is being handled by the
+service mesh, not the ingress controller, the A/B test can happen anywhere in
+the application's call graph.
+
+### How do I know this will be truly portable?
+
+Gateway API has been investing heavily in conformance tests across all
+features it supports, and mesh is no exception. One of the challenges that the
+GAMMA initiative ran into is that many of these tests were strongly tied to
+the idea that a given implementation provides an ingress controller. Many
+service meshes don't, and requiring a GAMMA-conformant mesh to also implement
+an ingress controller seemed impractical at best. This resulted in work
+restarting on Gateway API _conformance profiles_, as discussed in [GEP-1709].
+
+The basic idea of conformance profiles is that we can define subsets of the
+Gateway API, and allow implementations to choose (and document) which subsets
+they conform to. GAMMA is adding a new profile, named `Mesh` and described in
+[GEP-1686], which checks only the mesh functionality as defined by GAMMA. At
+this point, Kuma 2.3+, Linkerd 2.14+, and Istio 1.16+ are all conformant with
+the `Mesh` profile.
+
+## What else is in Gateway API v0.8.0?
+
+This release is all about preparing Gateway API for the upcoming v1.0 release
+where HTTPRoute, Gateway, and GatewayClass will graduate to GA. There are two
+main changes related to this: CEL validation and API version changes.
+
+### CEL Validation
+
+The first major change is that Gateway API v0.8.0 is the start of a transition
+from webhook validation to [CEL validation][cel] using information built into
+the CRDs. That will mean different things depending on the version of
+Kubernetes you're using:
+
+#### Kubernetes 1.25+
+
+CEL validation is fully supported, and almost all validation is implemented in
+CEL. (The sole exception is that header names in header modifier filters can
+only do case-insensitive validation. There is more information in [issue
+2277].)
+
+We recommend _not_ using the validating webhook on these Kubernetes versions.
+
+#### Kubernetes 1.23 and 1.24
+
+CEL validation is not supported, but Gateway API v0.8.0 CRDs can still be
+installed. When you upgrade to Kubernetes 1.25+, the validation included in
+these CRDs will automatically take effect.
+
+We recommend continuing to use the validating webhook on these Kubernetes
+versions.
+
+#### Kubernetes 1.22 and older
+
+Gateway API only commits to support for [5 most recent versions of
+Kubernetes][supported-versions]. As such, these versions are no longer
+supported by Gateway API, and unfortunately Gateway API v0.8.0 cannot be
+installed on them, since CRDs containing CEL validation will be rejected.
+
+### API Version Changes
+
+As we prepare for a v1.0 release that will graduate Gateway, GatewayClass, and
+HTTPRoute to the `v1` API Version from `v1beta1`, we are continuing the process
+of moving away from `v1alpha2` for resources that have graduated to `v1beta1`.
+For more information on this change and everything else included in this
+release, refer to the [v0.8.0 release notes][v0.8.0 release notes].
+
+## How can I get started with Gateway API?
+
+Gateway API represents the future of load balancing, routing, and service mesh
+APIs in Kubernetes. There are already more than 20 [implementations][impl]
+available (including both ingress controllers and service meshes) and the list
+keeps growing.
+
+If you're interested in getting started with Gateway API, take a look at the
+[API concepts documentation][concepts] and check out some of the
+[Guides][guides] to try it out. Because this is a CRD-based API, you can
+install the latest version on any Kubernetes 1.23+ cluster.
+
+If you're specifically interested in helping to contribute to Gateway API, we
+would love to have you! Please feel free to [open a new issue][issue] on the
+repository, or join in the [discussions][disc]. Also check out the [community
+page][community] which includes links to the Slack channel and community
+meetings. We look forward to seeing you!!
+
+## Further Reading:
+
+- [GEP-1324] provides an overview of the GAMMA goals and some important
+  definitions. This GEP is well worth a read for its discussion of the problem
+  space.
+- [GEP-1426] defines how to use Gateway API route resources, such as
+  HTTPRoute, to manage traffic within a service mesh.
+- [GEP-1686] builds on the work of [GEP-1709] to define a _conformance
+  profile_ for service meshes to be declared conformant with Gateway API.
+
+Although these are [Experimental][status] patterns, note that they are available
+in the [`standard` release channel][ch], since the GAMMA initiative has not
+needed to introduce new resources or fields to date.
+
+[gamma]:https://gateway-api.sigs.k8s.io/concepts/gamma/
+[status]:https://gateway-api.sigs.k8s.io/geps/overview/#status
+[ch]:https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard
+[cel]:/docs/reference/using-api/cel/
+[crd]:/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
+[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/
+[geps]:https://gateway-api.sigs.k8s.io/contributing/enhancement-requests/
+[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/
+[impl]:https://gateway-api.sigs.k8s.io/implementations/
+[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds
+[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose
+[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions
+[community]:https://gateway-api.sigs.k8s.io/contributing/community/
+[mesh-routing]:https://gateway-api.sigs.k8s.io/concepts/gamma/#how-the-gateway-api-works-for-service-mesh
+[GEP-1426]:https://gateway-api.sigs.k8s.io/geps/gep-1426/
+[GEP-1324]:https://gateway-api.sigs.k8s.io/geps/gep-1324/
+[GEP-1686]:https://gateway-api.sigs.k8s.io/geps/gep-1686/
+[GEP-1709]:https://gateway-api.sigs.k8s.io/geps/gep-1709/
+[issue 2277]:https://github.com/kubernetes-sigs/gateway-api/issues/2277
+[supported-versions]:https://gateway-api.sigs.k8s.io/concepts/versioning/#supported-versions
+[v0.8.0 release notes]:https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0
+[versioning docs]:https://gateway-api.sigs.k8s.io/concepts/versioning/

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

@@ -41,7 +41,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 * [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md) is an [Easegress](https://megaease.com/easegress/) based API gateway that can run as an ingress controller.
 * F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)
   lets you use an Ingress to configure F5 BIG-IP virtual servers.
-* [FortiADC Ingress Controller](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller-1-0/742835/fortiadc-ingress-controller-overview) support the Kubernetes Ingress resources and allows you to manage FortiADC objects from Kubernetes
+* [FortiADC Ingress Controller](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller/742835/fortiadc-ingress-controller-overview) support the Kubernetes Ingress resources and allows you to manage FortiADC objects from Kubernetes
 * [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io),
   which offers API gateway functionality.
 * [HAProxy Ingress](https://haproxy-ingress.github.io/) is an ingress controller for

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

@@ -258,7 +258,7 @@ overlays), the `emptyDir` may run out of capacity before this limit.
 {{< note >}}
 If the `SizeMemoryBackedVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
 you can specify a size for memory backed volumes.  If no size is specified, memory
-backed volumes are sized to 50% of the memory on a Linux host.
+backed volumes are sized to node allocatable memory.
 {{< /note>}}
 
 #### emptyDir configuration example

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

@@ -34,7 +34,7 @@ it should create to meet the number of replicas criteria. A ReplicaSet then fulf
 and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod
 template.
 
-A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-and-dependents)
+A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-dependents)
 field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning
 ReplicaSet's identifying information within their ownerReferences field. It's through this link that the ReplicaSet
 knows of the state of the Pods it is maintaining and plans accordingly.

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

@@ -158,7 +158,7 @@ There are some important considerations for the Kubernetes package repositories:
   over the package builds. This means that anything before v1.24.0 will only be
   available in the Google-hosted repository.
 - There's a dedicated package repository for each Kubernetes minor version.
-  When upgrading to to a different minor release, you must bear in mind that
+  When upgrading to a different minor release, you must bear in mind that
   the package repository details also change.
 
 {{< /note >}}