What other pod lifecycle events do we want to track?

[drmorr0]

Right now we just track pod start and end times. What else should we track and how do we configure that?

Some ideas:

1. Per-container start and end times
2. Per-container exit codes
3. ...?

Related question:

Right now we only track pod lifecycle events based on a configuration option in the tracer config. Should we instead track pod lifecycle events for all pods, and instead have an export filter to control whether we save them or not? (See also #63)

Another related question:

What happens if the pod lifecycle events that we're tracking don't match during a simulation replay? Would be good to offer users some ways to customize this behaviour (e.g., randomized and taken from a normal distribution of the tracked lifecycle data or from a user-specified distribution).

[vrutkovs]

I wonder if simkube could run a sidecar on kubeapiserver and "intercept" incoming requests. This would allow the tool to store all necessary details - and enable other usages other than pod scheduling / autoscaling

[drmorr0]

Yea, this is a great suggestion! I've chatted some other folks about something like this as well, but haven't had time (yet) to build it. Do you have a use case in mind?

The other thing I've had in the back of my head is a way to intercept and redirect network requests so that we can start simulating/reasoning about service mesh stuff, but that I think is an even bigger project.

[vrutkovs]

Not sure how important that would be for autoscaling, but it would be huge for:

• apiserver performance - effect of watch / lists, caching vs. etcd hits
• security - rbac processing, audit logs
• infra - is loadbalancer setup correctly when one of apiserver replicas is down