Use same code path for CLI injection and admission controller injection

[klingerf]

Once #1714 merges, it will be possible to install linkerd with an admission controller that automatically injects new deployments. The admission controller uses a YAML template from template.go to produce the injected sidecar configuration, whereas the CLI inject subcommand builds its configuration using Kubernetes objects. The net result is the same, but these two implementations could drift over time. We should standardize injection to use a single code path. cc @ihcsim.

[alenkacz]

@klingerf which of the two options for we want to lean to? Any preferences?

[ihcsim]

I think the proxy and proxy-init container specs generated in cli/cmd/inject.go should be used to populate the config map in template.go during install, instead of hard-coding it as seen in template.go.

[klingerf]

That's right -- when linkerd is installed with --proxy-auto-inject enabled, the install YAML includes a proxy-injector-sidecar-config ConfigMap. Right now, the contents of that ConfigMap are templated to mirror the output of running linkerd inject on a pod spec, but any changes to inject also need to be reflected in the template. It would be better to produce the template using the inject code itself.

Taking this one step further, however, I think an additional improvement could be to stop storing auto-inject YAML in the ConfigMap altogether, and instead store an object containing inject options, which we could then use to produce the YAML at auto-inject time. That would allow us to further standardize with the standard inject code path, by sharing this struct:

linkerd2/cli/cmd/root.go

Lines 133 to 153 in 38dfc53

	type proxyConfigOptions struct {
	linkerdVersion string
	proxyImage string
	initImage string
	dockerRegistry string
	imagePullPolicy string
	inboundPort uint
	outboundPort uint
	ignoreInboundPorts []uint
	ignoreOutboundPorts []uint
	proxyUID int64
	proxyLogLevel string
	proxyBindTimeout string
	proxyAPIPort uint
	proxyControlPort uint
	proxyMetricsPort uint
	proxyCpuRequest string
	proxyMemoryRequest string
	proxyOutboundCapacity map[string]uint
	tls string
	}

This would be a pretty sizable change, however.

[olix0r]

What do folks think about putting the entire inject logic into the public-api service? such that the inject command and the webhook can make an API call that takes yaml/json and receives yaml/json. This is especially useful if cluster-wide policy is set on the controller that needs to influence how injection is done. Relates to #1999

[klingerf]

@olix0r 👍 That sounds like a great idea to me. As part of this, I'd like for all of the auto-inject defaults to be passed as flags to the public-api service at install time, so that we don't need to store them in a separate configmap that's read by the proxy-injector service.

It's also the case the the proxy-injector has to supply its modifications in JSON Patch format. So it might make sense for the public-api endpoint to accept a format param, which dictates whether to return the injected object or the patch. Otherwise the proxy-injector will need to compare the injected YAML to the original YAML to create the patch.

[ihcsim]

This means the CLI inject command will call the public-api service directly, right? Does the CLI need to authenticate with the service, or is the public-service (as its name implies) public?

[olix0r]

@ihcsim i haven't thought deeply about implications around authorization; but in the short-term, this API is read-only and doesn't betray any private information. this may change depending on how TLS evolves.