I just found a bug in #37. When the leader is lost(mainly due to apiserver timeout), the program will stop watch events but will not exit，it will always hung there.
I modified this part of the logic in this pr. After the leader is lost, the program will exit the same as it received exit signal. Then a new pod will be scheduled to participate in the election.
Sorry for introducing this bug in # 37, hope this pr will fix it.
leader election function is disabled by default, and could be enabled by adding the
following section in `config.yaml`:
```yaml
leaderElection:
enabled: true
leaderElectionID: kubernetes-event-exporter // this field can be omited, default value is kubernetes-event-exporter
```
The config file may contain sensitive data such as credentials
for an elasticsearch cluster. To provide the possibility
to store that sensitive data in an other way, support for
environment variables is introduced. Sensitive data can then
be replaced by variables such as ${PASSWORD} and provided by
setting the appropriate environment variables. In kubernetes
the configuration and the sensitive data can be split up into
a configmap and a secret.
Before the change, the engine didn't call the `Close()` method of the
sinks. This is needed in some cases, i.e when a sink implementation is
buffered.
This change adds a `Close()` method to the registry that
will signal sinks to exit and wait for all sinks to exit before
returning. This is then used in the engine stop logic.
In the channel-based registry, the closing of all sinks is done in
parallel (using a `sync.WaitGroup`). In the sync registry, sinks are
closed sequentially.
Fixes issue #10
Mustafa Akin
youyongsong
Mustafa Akın
Martin Heck
Marc Demierre