Update instructions for Kustomize 5

[kimwnasptd]

Refs #2388

This PR updates the instructions and the example kustomization to work with Kustomize 5. Note that after this PR is merged users won't be able to use earlier versions of kustomize, since we need the sortOptions feature of Kustomize 5 #2388 (comment). This holds for the one-liner install. The manual instructions are not affected and people can use earlier versions of kustomize there.

Next work items, although not critical for the KF 1.7 release, are to update our manifests so that we don't see warnings from Kustomize #2388 (comment)

cc @DomFleischmann @annajung @juliusvonkohout @jbottum
/cc @kubeflow/wg-manifests-leads

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kimwnasptd

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 [kimwnasptd]

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

[annajung]

Thanks Kimonas! I couldn't recreate the race condition described in the #1797 with kustomize 5, but can confirm that with sortOptions added, it does create MutatingWebhookConfiguration before the necessary resources.

Testing with kustomize build example, only difference between kustomize5 with sortOptions enabled and kustomize3 was the order of when PVCs were created. It looks like kustomize3 places PVC at the end right before the ValidatingWebhookConfiguration, so kustomize5 order is preferrable IMO

lgtm (not adding the actual label to allow other folks to review)

there is still ongoing discussion on if it should be included in 1.7 release in #2388 but should not be a blocker for this PR.

[DomFleischmann]

Here is a suggestion for the Kustomize 3.2 QA section.

Suggested change

	**A:** Please refer to each individual component's documentation for a dependency compatibility range. For Istio, Knative, Dex, Cert-Manager and OIDC-AuthService, the versions in `common` are the ones we have validated.
	**A:** Please refer to each individual component's documentation for a dependency compatibility range. For Istio, Knative, Dex, Cert-Manager and OIDC-AuthService, the versions in `common` are the ones we have validated.
	- **Q: ** How can I still use Kustomize version 3.2?
	**A: ** The only change incompatible with Kustomize 3.2 is the `sortOptions` section in the `example/kustomization.yaml` file. I you want to use Kustomize 3.2 just comment out the entire section (`#` character in front of each line) and execute the one-liner.

[kimwnasptd]

@DomFleischmann I pushed a commit with a slightly refactored section for the earlier version of Kustomize. PTAL

[kimwnasptd]

Adding a summary here as well from the last community (Tue 28 Feb) and release meeting (Mon 6 March). We decided to move forward with using Kustomize 5 as the default installation tool.

The rationale is that:

1. With feedback until now we have heard from distros that they managed to use Kustomize 5 without any issues
2. There are no (currently known) deprecations that affect our use of kustomize
3. We'd like to move to a newer version of Kustomize, which hasn't been updated for a long time
4. We have documented a clear path on how people can use earlier versions of Kustomize, if they need to

So at this point we have confidence from both Manifests WG and feedback from distros that Kustomize 5 does not have any issues we haven't yet documented. Plus if adopters are not ready for the version switch they can still use an earlier version of kustomize. So let's move forward with this PR and also cherry-pick it to the KF 1.7 release branch

[DomFleischmann]

/lgtm