Deprecate k8s watchers in favor of k8s informers

[achrefbensaad]

Feature Request

Short Description

Currently we are making use of kubernetes watchers to listen for resource events. This has two side effect:

• Performance impact as we querying the api server at a constant rate even if there is no change in the data.
• Event loss.

Describe the solution you'd like

We should make use of k8s informers in order to solve the above mentioned problems.

Describe alternatives you've considered

• [ ] Use client go to make API calls #531
• [ ] Implement share informers in order to watch the required resources

[TheRealSibasishBehera]

Hi @achrefbensaad I would like to look into this issue , if nobody is working on this

[achrefbensaad]

Hi @TheRealSibasishBehera , Sure.

[nyrahul]

Hey @TheRealSibasishBehera , you have other issues assigned to you. Removing this one. Thank you for your active involvement.

[eugercek]

Hi @achrefbensaad I like to work on this issue if it's ok. I would appreciate some starting points, just to speed things up (only file:line), Issue's title is pretty self explanatory though.

[achrefbensaad]

Hi @eugercek, Sure. You can use this PR as a refrence.

[eugercek]

Hi, currently implementing informers on:

• WatchK8sNodes
• WatchK8sPods
• WatchK8sSecurityPolicies
• WatchK8sHostSecurityPolicies

I'm not sure what can be done in crioHandler dockerHandler and containerdHandler. I'd appreciate a suggestion.

[eugercek]

Also I want to get pre-confirmation on some deletions:

1. AFAIU WatchK8sSecurityPolicies is not used anymore, I'll delete it

2. I believe we won't need some of the fields (resourceFoo and resourceFooLock) in KubeArmorDaemon after informers update:

   • K8sPods
   • SecurityPolicies
   • HostSecurityPolicies

   • DefaultPostures

     If I don't miss an eventual consistency problem, we only use these fields for having local copy of the.
     current state while reacting to watch events, we don't use them in any other place. Informers already solve this problem so deleting these makes sense too. If we wan't a unified resource API, can create new struct like Store and write getters to leverage informers' indexers.