Poolmgr needs to know usage statistics for a function's pod. This
change asynchronously taps poolmgr API when router uses a service.
Poolmgr can use this information to control pod expiry. It may also
be useful later as one of the metrics for autoscaling.
Switch to client-go package instead of pulling the from kubernetes.
Use a versioned client with sensible compatiblity.
This change breaks 'go get'. For now you have to manually checkout
the 'release-1.4' branch of the client-go package after 'go get'
fetches it. TODO: use one of the build tools to fix this.
GenericPool is a pool of generic containers for an environment.
GenericPoolManager keeps track of all GenericPools, creating them
on-demand.
The pool manager API is simply a "lookup" for the service URL of a
function. If one exists it is returned immediately; otherwise, a
generic pool is created, and then a pod is specialized from that pool.
poolmgr is designed to run from within the cluster, since it connects
to pod IP addresses directly.
This is a first cut with many pieces missing.
TODO:
* Use versioned kubernetes clients instead of the unversioned one
* Unit tests for GenericPoolMgr; improve unit test for GenericPool;
test for API.
* Handle cases where a service exists but pod backing it has failed.
* On start up, use existing deployments/pods/services if they exist;
in other words don't orphan resources on restart.
* Kill idle resources (services, pods, even generic pools)
* Autoscale generic pool (for example, by watching num ready pods)
Soam Vasani