Reorganize configuration structure

[peterbom]

We currently have four environment variables affecting how Periscope runs.

• COLLECTOR_LIST
• DIAGNOSTIC_CONTAINERLOGS_LIST
• DIAGNOSTIC_KUBEOBJECTS_LIST
• DIAGNOSTIC_NODELOGS_LIST_(WINDOWS|LINUX)

The COLLECTOR_LIST variable allows users to affect which collectors run. But without looking at the code it's hard to know which values are valid, and how the values correspond to which collections of collectors.

The other settings only influence one collector each, which isn't apparent from the flat nature of the environment variables. Neither is it obvious what are the valid values for each of them:

• DIAGNOSTIC_KUBEOBJECTS_LIST must be formatted as a space-separated collection of <namespace>:<resourcetype>[:<resourcename>] and applies to the kubeobjects collector, which describes the matching resources.
• DIAGNOSTIC_CONTAINERLOGS_LIST is a space-separated collection of namespaces and applies to the podscontainerlogs collector, which gets the logs for all containers in all pods in those namespaces.
• DIAGNOSTICS_NODELOGS_LIST_* is a space-separated collection of filenames used by the nodelogs collector.

I think our configuration options could benefit from being more structured and descriptive.

Due to earlier changes, Periscope reads its configuration from a ConfigMap that's mounted as files within the container. So we could consider a single yaml formatted file whose structure more clearly reflects the configuration options E.g.

• options that only pertain to a particular collector could be within a section for that collector
• space-separated lists could be replaced by yaml lists
• custom formatting (x:y:z) could be replaced by yaml objects

We could still keep reading the existing environment variables to maintain backward compatibility, but a new structure would give us the opportunity to make the naming clearer and simplify how users choose which collectors run (a simple list of collector names might be more intuitive).

It should also make it more straightforward to add additional configuration in future. An example of this might be to support additional exporters in addition to blob storage.