- What is currently painful when building a controller
- Questions around best practices
- After this week
- As someone new:
- What is hard to grasp?
- As someone experienced:
- What important bits of info do you think are critical
- A lot of boilerplate
- Work queues
- HasSynced functions
- Re-queuing
- Lack of deep documentation in these areas
- Some documentation exists, bot focused on k/k core
- Securing webhooks & APIServers
- Validation schemas
- TLS, the number of certs is a pain point
- It is hard right now, the internal k8s CA has been used a bit.
- OpenShift has a 'serving cert controller' that will generate a cert based on an annotation that might be able to possibly integrate upstream.
- Election has been problematic and the Scaling API is low-level and hard to use.
- Registering CRDs, whats the best way to go about it?
- No best way to do it, but has been deployed with application
- Declarative API on one end that has to be translated to traslated to a transactional API on other end (e.g. ingress). Controller trying to change quite a few things.
- You can do locking, but it has to be built.
- Follow-up where a CRD has to work with an external or third party system, unsure on how to roll-back or
undo.- Need a record that keeps track of things in progress. e.g. status. Need more info on how to properly tackle this problem.
- How many times to update status per sync
- based on type of object
- Conditions vs fields
- "don't use conditions too much", status is unsure
- "What Does condition mean in this context
- Additional field that can have
readywith a msg, representsstate. - Limit on states that the object can be in.
- Use conditions to reflect the state of the world, is something blocked etc.
- Conditions were created to allow for mixed mode of clients, old clients can ignore some conditions while new clients can follow them.
- Additional field that can have
- Validating webhooks vs OpenAPI schema
- How are people testing extensions?
- Anyone reusing upstream dind cluster?
- People looking for a good way to test them.
- kube-builder uses the sig-testing framework to bring up a local control plane and use that to test against.
- Spin up a full cluster with kubeadm and run tests against that
- Mirtantis has a tool for a multi-node dind cluster for testing
- When to use subresources?
- Are people switching to api agg to use this today?
- Really just for status and scale
- How can we best disseminate this knowledge?
- Shaed among many areas, most SIGs maintain controllers
- Wiki? Developer Docs working group?
- Existing docs focus on in-tree development. Dedicated 'extending kubernetes' section?
- How to generate reference style documentation?
- Can use kube-builder to generate better documentation - kube-builder 'book' in the works - http://book.kubebuilder.io/
- How many versions of kubernetes do people test against?
- auidence poll: 2-3
- sig-platofmr-dev
- Client-go generated listers, what is the reason for two separate interfaces to retrieve from client and cache?
- historical, but some things are better done local vs on the server.
- What is the best question going forward for now?
- most goes to sig-api-machinery right now
- Controller related stuff would probably be best for sig-apps
- Staleness of data, how are people dealing with keeping data up to date with external data?
- Specify sync period on your informer, will put everything through the loop and hit external resources.
- With strictly kubernetes resources, should your sync period be never? aka does the watch return everything.
- The watch should return everything and should be used if its strictly k8s in and k8s out, no need to set the sync period.
- What about controllers in other languages than go?
- metacontroller