Just Make API Objects!
lavalamp/dbsmith * 2019-04-03 * status: opinion piece * PUBLIC
Problem: kube-apiserver sometimes needs to coordinate with other replicas of itself. Today, we don’t do it (e.g., API Service / CRD status), or do it in an ad-hoc, non transparent way (e.g., IP allocations).
Suggested solution pattern:
Make a regular Kubernetes API Object
Install it in a sensible group.
Access the objects via the apiserver self-client
RBAC the collections such that only the apiserver self-client and super admins can mutate the objects.
Reasoning:
We need to handle forward/backwards compatibility. We already built a thing for that.
This needn’t slow us down; we don’t necessarily have to keep a deprecation policy as extreme as the usual one, since we discourage clients other than apiserver itself.
No up-front investment is necessary, all the pieces exist.
This permits external introspection into apiserver internal state.
Debugging!
On the off chance it’s needed, it’ll be possible to fix the state!
List of apiserver responsibilities that could benefit from this pattern:
Coordinating which CRDs are currently being served
Coordinating which APIServices are currently being served
Generally speaking, the expanded discovery doc.
Coordinating global apiserver settings / flag-flips
Serving certs
Storage versions & enabled apis
Feature gates (!)
...without surveying, I expect 50%-80% of our flags ought to be consistent between apiserver replicas
Service IP allocations / Node port allocations
apiserver endpoint management (we sort of already do this by weirdly self-managing the apiserver endpoints record)
--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAB_J3bZfryvK547eAmKvgbfvET7RvMH2osdcwyS%3D%2BwN_jgGycw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKCBhs69bakbnaJ0EXSu8UJzXqgfTj708F2vOos_48ksCs7yTQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAPgfqyWWTaJ9FgTHDT7GpOc%3DQ9vS9zqQ26R2NCQ%2B27RZz%3DjvDQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFS1MjLeBsasei-t1RTuQD6wMxY%3Dy_PAei5Y_C7AUDJdahXsOQ%40mail.gmail.com.
+1. This is the use case etcd was originally designed for. Might want to think about doing this with controller manager as well. Agree with David that we need to decide what configuration is dynamic.Thanks,-KenOn Thu, Apr 4, 2019, 5:23 AM David Eads <de...@redhat.com> wrote:I'm ok with the idea in general (not as excited as others perhaps), but the kube-apiserver wasn't designed or built with dynamic config capabilities in mind for most values.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAB_J3bZAOjabtrJrVww5mOczPSX_2pwKLCnUyChCjQhnC-BtvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.