avoid 6 api rpm per pod by removing operator framework cache-reset

[grosser]

we see requests to all api endpoints every minute coming from the k8sclient.GetKubeClient being hardcoded to reset every minute here

not calling operator sdk did not help (doing this)

	kubeConfig, err := rest.InClusterConfig()
	if err != nil {
		panic(err)
	}
	kubeClient := kubernetes.NewForConfigOrDie(kubeConfig)

so I had to disable the cache-reset in operator-sdk

no more api spam now 🎉

so I'd suggest either using that branch (kinda shady) or updating operator sdk (bunch of work I guess) or getting rid of operator-sdk (also lots of work) 😞

[mogren]

@grosser Thanks a lot for looking at this. We are working fixing the issues related to Custom Networking. There are multiple issues directly related to the old version of the operator framework that we have. (Related issue in aws/containers-roadmap#867.)

Like you said, migrating from 0.0.7 to something newer isn't trivial, but given that v1.0.0 was just released, it's time to do something about this.

[grosser]

idk how stable newly baked 1.0 will be though :D
... I did not dig deep enough to understand why operator-sdk is needed, so my naive suggestion would be to try and replace it with native code bit-by-bit and get rid of that big dependency

[mogren]

@grosser The operator-framework is used for the Custom Networking to work with the ENIConfig CRD. The last attempt to replace it was this PR #560, but as you can see, replacing it isn't trivial. Also, I agree that a v1.0.0 is probably not something we want to depend on, but I suspect that there will be a release or two before custom networking has been rewritten. Alternatively, we would go with v0.19.3 since that is an even more recent release.

[jayanthvn]

With CNI 1.8, we have removed the dependency on operator-sdk - #1419. I think we don't need this PR anymore.