Allow using K0S_TOKEN environ as source of Join token

[s3rj1k]

Implements ability to pass Join token via K0S_TOKEN environ.

How to test (Needs 3 test nodes):

CP Node 1
    k0s install controller \
        --enable-dynamic-config \
        --disable-components=konnectivity-server \
        --enable-worker \
        --no-taints \
        --kubelet-root-dir=/var/lib/kubelet \
        --verbose
    systemctl enable --now k0scontroller

    k0s token create
    k0s token create --role controller

Worker Node 1
    k0s install worker --env K0S_TOKEN="***" --kubelet-root-dir=/var/lib/kubelet --verbose
    systemctl enable --now k0sworker

CP Node 2
    k0s install controller \
        --enable-dynamic-config \
        --disable-components=konnectivity-server \
        --enable-worker \
        --no-taints \
        --kubelet-root-dir=/var/lib/kubelet \
        --env K0S_TOKEN="***" \
        --verbose
    systemctl enable --now k0scontroller

This is alternative to #6755

[twz123]

Can you add some sentences / an example about the environment variable to the documentation, e.g. to k0s-multi-node.md?

[twz123]

I wouldn't make the presence of the environment variable a hard error. It should rather be a fallback if the token hasn't been passed as an arg or via the file flag.

[s3rj1k]

It would be unclear in that case what token was used, do you want to add ambiguous behavior and solve that by extending documentation and telling people why passing token via env won't take precedence over a flag?

[twz123]

I guess it's standard behavior, isn't it? We have a flag (although it's an optional arg in this case), and a related environment variable as a fallback. If the flag (arg) is present, it'll use that, if the flag is missing, it'll fall back to the env.

[s3rj1k]

no, it is not standard, what you are describing is optional reconfiguration with environ, PR is after having a clear way of setting token only with one option and if that fails report error instead of trying to run k0s cluster and fail expectation

[twz123]

I'd prefer to leave this check in place (or refactor it out and reuse it here via a function, whichever makes more sense.) We should verify the command line's correctness before attempting to do anything.

[s3rj1k]

hopefully handled by internal.CheckSingleTokenSource