WIP: simple discovery server #17818
WIP: simple discovery server #17818
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
cncf-cla: yes
justinsb
force-pushed
the
discovery
branch
2 times, most recently
from
8396a06 to
eead354
Compare
| MinVersion: tls.VersionTLS12, | ||
| } | ||
|
|
||
| server := &http.Server{ |
There was a problem hiding this comment.
http3 ? I had white wine before
There was a problem hiding this comment.
Sorry, I don't get it ... would you like to use http3? Have I opted in to http3 automatically? Do you want us to be the "guinea pig" for http3 in kube (if so, I'm game!)
I don't think there's anything special we need from http3. We do need the client certificate information. I was thinking we would probably end up deploying this directly behind an L4 load balancer, or (failing that) using ingress or gateway with SNI routing.
In terms of backends, right now I have this with a simple in-memory implementation. Honestly that's probably good enough to get started, as we will not be offering any guarantee as to retention of these objects.
But ... if we wanted to do better, I think we should put them into etcd because (1) we should be able to run etcd pretty cheaply and we don't have to worry about wracking up a huge GCS bill if someone figures out how to make us send queries to GCS etc and (2) it means that we can use etcd-operator, which would be good from the "all the wood behind one arrow" perspective
discovery/docs/kubeconfig.md
Outdated
| @@ -0,0 +1,82 @@ | |||
| # Using kubectl with Discovery Service | |||
|
|
|||
| Since the Discovery Service now emulates the Kubernetes API for `DiscoveryEndpoint` resources, you can use `kubectl` to interact with it. | |||
There was a problem hiding this comment.
I'm going to ask gemini to clean up these instructions / demo scripts.
discovery/pkg/discovery/k8s_types.go
Outdated
| } | ||
|
|
||
| // DiscoveryEndpoint represents a registered client in the discovery service. | ||
| type DiscoveryEndpoint struct { |
There was a problem hiding this comment.
I should move this to apis/discovery.kops.k8s.io/v1alpha1 for consistency (and probably change the version to v1alpha1)
| { | ||
| Name: "discoveryendpoints", | ||
| SingularName: "discoveryendpoint", | ||
| Namespaced: true, |
There was a problem hiding this comment.
I think this probably should be cluster scoped, although I guess we could use the namespace to indicate the cluster if we we wanted to allow multiple clusters to share the same CA (which isn't a terrible idea if someone is doing multicluster).
|
|
||
| require ( | ||
| k8s.io/apimachinery v0.34.3 | ||
| k8s.io/client-go v0.34.3 |
There was a problem hiding this comment.
Technically client-go / apimachinery is only used by the clients / tests, so it might be nice to split them out. But to do that would require a separate go.mod, which is a bit of a pain.
justinsb
force-pushed
the
discovery
branch
2 times, most recently
from
30cb54f to
62736c6
Compare
3 participants
No description provided.