Automatically set GOMAXPROCS in sharedmain

[julz]

Expected Behavior

GOMAXPROCS for controllers is correctly set when deployed in a container with a cpu limit.

Actual Behavior

Container GOMAXPROCS are set as if they have access to all the cpus on the host

Steps to Reproduce the Problem

1. Deploy e.g. knative serving
2. Check GOMAXPROCS of e.g. autoscaler (which has cpu limit of 300m = less than 1 cpu)
3. See that GOMAXPROCS is set to number of CPUs on host :-( (on my Minikube with 10 CPUs, it's set to 10).

Some context/other threads:

• runtime: make GOMAXPROCS cfs-aware on GOOS=linux golang/go#33803 (Golang issue)
• The variable GOMAXPROCS does not work properly in Container environment prometheus/prometheus#6413
• Pilot gets cpu throttled because GOMAXPROCS not set istio/istio#20264

Proposed solution:

We could use something like https://github.com/uber-go/automaxprocs to fix this. Or we could explicitly set GOMAXPROCS env variable in our yamls to match set quotas, but that won't work well if operators change the limits. Or we could wait for upstream Go to fix this (See linked issue above), but it looks like this is no longer landing soon.

I think personally https://github.com/uber-go/automaxprocs seems like a reasonable approach here since it copes better with someone using the operator to bump cpu quotas, but would like to see if anyone has concerns with that before PRing :-)

/assign @vagababov @markusthoemmes mattmoor

[vagababov]

well, since you assigned to me — me gonna just do it? 😃
This seems reasonable enough to just use automaxprocs, until golang is fixed itself.

[julz]

ha! well I have a PR ready, I was assigning for people to tell me it's a bad idea before I send it :)

[julz]

Pushed the PR :) #1585

[vagababov]

💭