The Kubernetes Event generation, filtering and propagation considerations for component owners and destination architect:
1) A Kubernetes Label is what makes a regular K8s (short for Kubernetes) event a Selected event. This label is not something that the Selected team can do without. It is their criteria in their configmap with saying “matchOn” with a name. They cannot create alternate criteria that says matchOn level = critical or events with remedies. This is a label that they need the event generators to decide and add-on. Therefore, we must work with some of their limitations here. At the same time the event promotion rules is a good idea and having a set for criteria for the rules is helpful to anyone. If the criteria is specific to a component or to Selected, then its best to put it in their corresponding ConfigMap.
2) 1) does not mean we have to generate Selected events only. In fact, we should generate K8S events because with or without the criteria for Selected, this only improves the diagnostics of the component and it is something that only the component owners know best.
3) The advice for the component owner has been generate more K8s events. However, the Kubernetes also raised K8s events for almost all resources. Therefore, there should not be any overlap between the events raised by the Kubernetes by default and those from the component
4) In the past, we have discussed a layered approach to publishing K8s events, promoting K8s events to Selected events which in turn gets notified to Special events . There has been speculation about how Selected picks these events or should be doing so in the future. I suggest that picking and promoting events based on matchOn and rules is something that any layer can do. Therefore, it is better to separate the event generation from the event propagation. These operations are not the dedicated responsibility of any single component or layer but something that can be performed by each if they choose as such.
5) The event generation has also been different from different components but anything to do with the operational aspect is welcome. The difference has been to justify emitting events to authoring the resources with states so that Kubernetes automatically emits the events.
6) In some cases, the native K8s events don’t have enough information or message. They could be enhanced with identifiers and names that may assist SRS and other consumers by finding everything in the event itself.
7) The most important aspect for any specific component has been 5) and 6) above because it handles requests for all service instances and service bindings which are dynamic during the lifetime of the product and the source for most troubleshooting tickets.
8) As the service catalog does not capture the context in which these instances and bindings are created, we have an opportunity to improve these from this component.
9) Lastly, I want to add that the handlers of Special events are concerned about having few events rather than a flood of events. Unlike other products which don’t have infrastructure like Kubernetes, events can be numerous. Therefore, this restriction for number of events must be removed from both special events handlers and user interface otherwise the customers will not benefit as much from these events.
1) A Kubernetes Label is what makes a regular K8s (short for Kubernetes) event a Selected event. This label is not something that the Selected team can do without. It is their criteria in their configmap with saying “matchOn” with a name. They cannot create alternate criteria that says matchOn level = critical or events with remedies. This is a label that they need the event generators to decide and add-on. Therefore, we must work with some of their limitations here. At the same time the event promotion rules is a good idea and having a set for criteria for the rules is helpful to anyone. If the criteria is specific to a component or to Selected, then its best to put it in their corresponding ConfigMap.
2) 1) does not mean we have to generate Selected events only. In fact, we should generate K8S events because with or without the criteria for Selected, this only improves the diagnostics of the component and it is something that only the component owners know best.
3) The advice for the component owner has been generate more K8s events. However, the Kubernetes also raised K8s events for almost all resources. Therefore, there should not be any overlap between the events raised by the Kubernetes by default and those from the component
4) In the past, we have discussed a layered approach to publishing K8s events, promoting K8s events to Selected events which in turn gets notified to Special events . There has been speculation about how Selected picks these events or should be doing so in the future. I suggest that picking and promoting events based on matchOn and rules is something that any layer can do. Therefore, it is better to separate the event generation from the event propagation. These operations are not the dedicated responsibility of any single component or layer but something that can be performed by each if they choose as such.
5) The event generation has also been different from different components but anything to do with the operational aspect is welcome. The difference has been to justify emitting events to authoring the resources with states so that Kubernetes automatically emits the events.
6) In some cases, the native K8s events don’t have enough information or message. They could be enhanced with identifiers and names that may assist SRS and other consumers by finding everything in the event itself.
7) The most important aspect for any specific component has been 5) and 6) above because it handles requests for all service instances and service bindings which are dynamic during the lifetime of the product and the source for most troubleshooting tickets.
8) As the service catalog does not capture the context in which these instances and bindings are created, we have an opportunity to improve these from this component.
9) Lastly, I want to add that the handlers of Special events are concerned about having few events rather than a flood of events. Unlike other products which don’t have infrastructure like Kubernetes, events can be numerous. Therefore, this restriction for number of events must be removed from both special events handlers and user interface otherwise the customers will not benefit as much from these events.
No comments:
Post a Comment