Declarative / deterministic configuration

[m1o1]

I'm trying to set up linkerd to be as declarative and deterministic as possible for installs/upgrades.

Ideally I was picturing something like linkerd upgrade --install -f values.yaml like helm, but using the linkerd CLI. If something like this isn't possible without helm we can switch but I was curious what options there are with the CLI.

Trying to make a pipeline that is:

• Deterministic: If I configure linkerd with a values.yaml to override some default values, when I remove a field from this file later, I'd like it to use the default again instead of picking up what's in the configmap/secret in the cluster.
• Declarative: I like the idea of using yaml files for configuration instead of command line flags with multiple CLI commands
• Easily maintainable: If I use something like --from-manifests when upgrading, I don't want to have to maintain the list of all config values including defaults. This is too difficult to keep up when default values are added/removed/changed.

Conflicting with my first goal, I'd like to not have to specify the TLS certificates every time. Ideally, I'd have one pipeline that maintains / upgrades linkerd itself, and another one responsible for certificates. Maybe there are some other config values I'd like to "reuse" at some point, but for now just the certs.

I was picturing something like:
linkerd upgrade --install --from-manifests values.yaml --set-secret {secret-to-reuse-values-from}

(where any field not set in values.yaml would get default values - not based on any existing values - and values in the specified secret would override values specified in the values.yaml manifests and defaults)

I found a discussion about the different config options, but it's not clear to me if this info is up to date or just a proposal. It seems that way since the configmap is still in use. If there are docs on these different configmaps/secrets, I can't seem to find them.

Any help is appreciated!

[olix0r]

Ideally I was picturing something like linkerd upgrade --install -f values.yaml like helm, but using the linkerd CLI. If something like this isn't possible without helm we can switch but I was curious what options there are with the CLI.

What problems does helm introduce for you? The Linkerd CLI is a small wrapper around helm, internally. For real production use cases, we generally recommend using Helm directly.

I'd like to not have to specify the TLS certificates every time

You can configure Linkerd to use externally-provided certificates. Generally, we see people using cert-manager and trust to accomplish this sort of thing. This should work with either the CLI or Helm.

[m1o1]

If it's recommended for production then we will switch to use helm instead. I assumed the CLI was the recommended approach. In the past we found Istio hard to use with helm (how it handles CRDs, etc.), and helm didn't seem to have the same level of support as using the CLI (though linkerd definitely seems better in that regard). Plus there are some verifications that the CLI could do that don't seem possible with helm (maybe with helm hooks?) such as verification of certificates, disallowing version upgrades that are not to the next minor version, or disallowing upgrades if the data plane is not running the same version as the control plane. Our pipeline can verify the latter two with the linkerd check though.

The only thing that concerns me is how often we'll need to uninstall a helm release as described in the last release notes. I don't suppose this is something that will be frequent but especially in HA deployments this could cause down-time, especially in our use case where we are dynamically creating and tearing down new Deployments several times per day.

[kleimkuhler]

@m1o1 I understand your hesitation about breaking changes with the Helm installation, but its unlikely we'd have something like this occur again for the foreseeable future. This is a change we've been working towards for a few months now and wanted to make sure it baked in a few edges before being part of the next stable release. Hopefully you don't see that as a blocker for moving to Helm.