Use docker/CRI to discover pods at node init

[fawadkhaliq]

Issue #711

Description of changes:
ipamd nodeInit relies on pod discovery watcher to get the list of running pods. The watcher and ipamd are launched in parallel. This can lead to a race condition where ipamd getLocalPodsWithRetry kicks in before the watcher is done with listing all the running pods on a node. If this happens, ipamd may end up allocating in-use IP addr to new pods

Changes

• Changed ipamd to query docker/CRI to discover the list of node local pods instead Kubernetes API
• Add support in the cri.go to get IP address of a pod and added IP field to cri.SandboxInfo
• Datastore inputs changed from k8sapi.K8SPodInfo to cri.SandboxInfo

Alternative considered

• Instead of using the watcher, make a blocking list pods call to the Kubernetes API server directly. This approach does not guarantee accurate state. On an overloaded system, API server might lag behind the node local state returning. While this approach would solve the original race condition, it can still return a different view of the running pods (eventually consistent)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mogren]

Nice, LGTM!

[jayanthvn]

TODO - in 1.7 we might want to rename localPods to something like localRunningSandboxes