You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Note that the `fake.go` file has no unit test coverage as it is a utility designed to be used by integration tests. The rest of the files in the package have 90+ coverage.
@@ -620,7 +625,11 @@ main focus will be on kubectl and golang clients.
620
625
621
626
#### GA
622
627
623
-
- TBD
628
+
- Existing bugs are fixed:
629
+
- AggregatedDiscovery controller does not purge old APIServices from cache ([Issue](https://github.com/kubernetes/kubernetes/issues/115301))
630
+
- Aggregated Discovery doesn't show aggregated apiservices as Stale before initial health check ([Issue](https://github.com/kubernetes/kubernetes/issues/115303))
631
+
- New API type `apidiscovery.k8s.io/v2` is introduced
632
+
- e2e and conformance tests
624
633
625
634
**Note:** Generally we also wait at least two releases between beta
626
635
and GA/stable, because there's no opportunity for user feedback, or
@@ -633,6 +642,7 @@ include [conformance tests].**
633
642
634
643
#### Deprecation
635
644
645
+
Once Aggregated Discovery v2 types are GA, v2beta1 types will be deprecated and removed after 3 releases.
636
646
637
647
### Upgrade / Downgrade Strategy
638
648
@@ -641,6 +651,31 @@ feature and upgrade/downgrade is not a problem.
641
651
642
652
### Version Skew Strategy
643
653
654
+
When moving from beta to GA, we will introduce a new API group version `apidiscovery.k8s.io/v2`.
655
+
656
+
All clients v1.26 to v1.29 will only request for the beta API group version `apidiscovery.k8s.io/v2beta1`.
657
+
658
+
To accommodate skew between the client and server (older client and newer server), the server will serve both v2 and v2beta1 versions based on the client request headers. The API server will continue to support v2beta1 until its removal in Kubernetes v1.33.
659
+
660
+
To accommodate skew between an older server and newer client, starting in v1.30,
661
+
client-go will request for both v2 and v2beta1 by sending a list of group versions
662
+
requested (in order from v2, v2beta1, unaggregated) and the server will return the
663
+
first group version that matches. Concretely, this is done using `Accept` headers with a single request.
In the case of older servers, the server will only
670
+
be able to match v2beta1. The client will support both v2 and v2beta1. This allows a
671
+
newer client to communicate with an older server that supports only the beta version.
672
+
Other clients should follow the same convention to support version skew, though a client
673
+
that is only capable of processing v2 is sufficient if it only communicates with v1.30+ servers.
674
+
Otherwise, the client will need to be ready to tolerate a 406 Not Acceptable response and handle
675
+
the error appropriately.
676
+
677
+
If there is no skew and both server and client are v1.30+, clients will still request for v2 and v2beta1, and the server will match the first group version and return v2.
678
+
644
679
## Production Readiness Review Questionnaire
645
680
646
681
<!--
@@ -839,6 +874,10 @@ high level (needs more precise definitions) those may be things like:
839
874
These goals will help you determine what you need to measure (SLIs) in
840
875
the next question. -->
841
876
877
+
Aggregated Discovery falls under a non-streaming read-only API call which is defined under the Kubernetes API call latency
0 commit comments