Identify quota changes needed for ingress jobs, create pool of ingress projects

[spiffxp]

This is like #851 but for ingress

The default quotas for an e2e project (eg: k8s-infra-e2e-gce-project) MAY be insufficient to run ci-kubernetes-e2e-gci-gce-ingress

Currently this job runs in the google.com k8s-prow-builds cluster, using a project from that boskos' ingress-project pool

• Identify whether ci-kubernetes-e2e-gci-gce-ingress can run against a stock e2e project (it can! so this is much lower priority, since we don't need ingress projects for release/merge-blocking job migration)
• Identify what quotas are set that make ingress-projects differ from a default e2e project
• Identify what jobs this will allow us to migrate
• Identify pool size
• Provision pool in kubernetes.io org
• Add pool to k8s-infra-prow-build's boskos

[spiffxp]

$ for prj in k8s-ingress-boskos-01 k8s-infra-e2e-ingress-project; do
  gcloud compute project-info describe --project=$prj > $prj.compute-project-info.yaml
done
$ diff -yW80 k8s-infra-e2e-ingress-project.compute-project-info.yaml k8s-ingress-boskos-01.compute-project-info.yaml | grep -A3 "|.*limit"
- limit: 21.0			      |	- limit: 50.0
  metric: STATIC_ADDRESSES		  metric: STATIC_ADDRESSES
  usage: 0.0				  usage: 0.0
- limit: 250.0				- limit: 250.0
--
- limit: 45.0			      |	- limit: 100.0
  metric: FORWARDING_RULES		  metric: FORWARDING_RULES
  usage: 0.0				  usage: 0.0
- limit: 150.0				- limit: 150.0
--
- limit: 150.0			      |	- limit: 55.0
  metric: HEALTH_CHECKS			  metric: HEALTH_CHECKS
  usage: 0.0				  usage: 0.0
- limit: 69.0			      |	- limit: 100.0
  metric: IN_USE_ADDRESSES		  metric: IN_USE_ADDRESSES
  usage: 0.0				  usage: 0.0
- limit: 150.0				- limit: 150.0
--
- limit: 30.0			      |	- limit: 50.0
  metric: TARGET_HTTP_PROXIES		  metric: TARGET_HTTP_PROXIES
  usage: 0.0				  usage: 0.0
- limit: 30.0			      |	- limit: 50.0
  metric: URL_MAPS			  metric: URL_MAPS
  usage: 0.0				  usage: 0.0
- limit: 9.0			      |	- limit: 100.0
  metric: BACKEND_SERVICES		  metric: BACKEND_SERVICES
  usage: 0.0				  usage: 0.0
- limit: 300.0				- limit: 300.0
--
- limit: 30.0			      |	- limit: 50.0
  metric: TARGET_HTTPS_PROXIES		  metric: TARGET_HTTPS_PROXIES
  usage: 0.0				  usage: 0.0
- limit: 30.0			      |	- limit: 50.0
  metric: SSL_CERTIFICATES		  metric: SSL_CERTIFICATES
  usage: 0.0				  usage: 0.0
- limit: 175.0				- limit: 175.0
--
- limit: 100.0			      |	- limit: 200.0
  metric: SECURITY_POLICY_RULES		  metric: SECURITY_POLICY_RULES
  usage: 0.0				  usage: 0.0
- limit: 45.0				- limit: 45.0
--
- limit: 300.0			      |	- limit: 1000.0
  metric: NETWORK_ENDPOINT_GROUPS	  metric: NETWORK_ENDPOINT_GROUPS
  usage: 0.0				  usage: 0.0
- limit: 6.0				- limit: 6.0
--
- limit: 15.0			      |	- limit: 50.0
  metric: EXTERNAL_VPN_GATEWAYS		  metric: EXTERNAL_VPN_GATEWAYS
  usage: 0.0				  usage: 0.0
- limit: 1.0				- limit: 1.0
--
- limit: 1024.0			      |	- limit: 128.0
  metric: STATIC_BYOIP_ADDRESSES	  metric: STATIC_BYOIP_ADDRESSES
  usage: 0.0				  usage: 0.0

[spiffxp]

Jobs that use this project type:

• ci-cri-containerd-e2e-gci-gce-ingress
• ci-ingress-gce-e2e
• ci-ingress-gce-e2e-multi-zone
• ci-ingress-gce-e2e-release-1-6
• ci-kubemci-ingress-conformance
• ci-kubernetes-e2e-gce-cos-k8sbeta-ingress
• ci-kubernetes-e2e-gce-cos-k8sstable1-ingress
• ci-kubernetes-e2e-gce-cos-k8sstable2-ingress
• ci-kubernetes-e2e-gce-cos-k8sstable3-ingress
• ci-kubernetes-e2e-gci-gce-ingress
• ci-kubernetes-e2e-gci-gce-ingress-manual-network

[spiffxp]

/assign

[spiffxp]

Will use kubernetes/test-infra#18663 as a canary job, should be able to let it schedule (or re-run it) to see if I've gotten quotas correct

I'm starting with no increase in quotas at all

[spiffxp]

https://testgrid.k8s.io/sig-testing-canaries#gci-gce-ingress&width=20&graph-metrics=test-duration-minutes - so it, uh, looks like the release-blocking ingress job runs just fine with the default quotas

https://testgrid.k8s.io/sig-release-master-blocking#gci-gce-ingress&width=20&graph-metrics=test-duration-minutes - and comparing to the sig-release-master-blocking runs, it performs basically the same as well

So this task isn't strictly necessary to migrate release-blocking jobs. Are there any presubmits I'm missing?