Support registering APIService in envtest

[timebertt]

Currently, envtest primarily supports controllers working on resources registered by CRDs.
We would like to leverage envtest for writing integration tests for resources provided by an extension API server and registered via APIServices as well.

[timebertt]

With #1449 it's now possible to configure the test environment's API server's aggregation layer in order to register APIServices like in a usual cluster.

Example:

testEnv.ControlPlane.APIServer.Args = append(envtest.DefaultKubeAPIServerFlags,
	"--client-ca-file={{ .CertDir }}/apiserver-ca.crt",
	"--proxy-client-key-file={{ .CertDir }}/apiserver.key",
	"--proxy-client-cert-file={{ .CertDir }}/apiserver.crt",
	"--requestheader-client-ca-file={{ .CertDir }}/apiserver-ca.crt",
	"--requestheader-extra-headers-prefix=X-Remote-Extra-",
	"--requestheader-group-headers=X-Remote-Group",
	"--requestheader-username-headers=X-Remote-User",
)

// start testEnv...
// start extension API server (configure delegating authn/authz as usual)
// create client with `apiregistration` in its scheme...

err := c.Create(ctx, &apiregistrationv1.APIService{ /* ... */ })

// talk to extension API server as usual
err = c.List(ctx, &yourextendedapi.SomeResourceList{})

See example usage for a more details.

[timebertt]

Let me know, if there is interest in simplifying this scenario even further.
We could offer registering APIServices similar to CRDs (i.e. CRDInstallOptions) and optionally configure the aggregation layer for it accordingly.

Though, I assume that most folks using controller-runtime are rather working with CRDs, which are already well-supported by envtest.

[timebertt]

here is an updated example for how to configure the aggregation layer in envtest with controller-runtime@v0.9.0 and #1541.
It generates dedicated front-proxy CA/cert/key and configures the respective API server flags.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[timebertt]

Sine envtest mainly target's controllers working on CRDs and given that it's still fairly simple to register an APIService nowadays (described in #1448 (comment)), I think we can close this issue.
/close

[k8s-ci-robot]

@timebertt: Closing this issue.

In response to this:

Sine envtest mainly target's controllers working on CRDs and given that it's still fairly simple to register an APIService nowadays (described in #1448 (comment)), I think we can close this issue.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.