Use non-experimental version of encryption provider config flag in 1.13+

[zacblazic]

As of kubernetes 1.13, the --encryption-provider-config flag should be used instead of the variant that provided alpha support for the feature.

From https://v1-13.docs.kubernetes.io/docs/setup/release/notes/#deprecations:

The --experimental-encryption-provider-config flag is deprecated in favor of --encryption-provider-config. The old flag is accepted with a warning but will be removed in 1.14.

[k8s-ci-robot]

Hi @zacblazic. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[rifelpet]

/ok-to-test

[joshbranham]

Looks like we are still discussing a formal deprecation policy, but wondering what the thought here is on the old flag. I agree that it should be a new field so it's clear what is happening for 1.13+, but maybe we should also be alerting users via kops update cluster if they are using the --experimental-encryption-provider-config flag still?

[johngmyers]

/test pull-kops-verify-staticcheck

[hakman]

@joshbranham from the user's point of view this change is transparent. The config option remains the same: Cluster.Spec.EncryptionConfig, so no need for a warning.

I see in code that the "experimental" flag was not yet removed, so at least nothing is broken.

[justinsb]

This looks good to me; we maybe should only introduce it to newer k8s versions (so we don't change configuration for older kubernetes versions), but they are aliases to each other, and they are so similar I don't think they are going to cause any confusion.

We could (separately) warn if someone is explicitly specifying experimentalEncryptionProviderConfig - but as a typical user won't do this I don't think we need to - we don't make compatibility guarantees for the flag-level settings.

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, zacblazic

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Nilubkal]

Will this change be ported into v1.17 too ?