Update Kubernetes to v1.23

[brandond]

Proposed Changes

• Move containerd out to a separate binary
  Moved to Standalone containerd #4757
• Fix CI issues
  Moved out to Fix multiple CI issues blocking 1.23 release #4801
• Update Kubernetes to 1.23
• Update golang to 1.17

Types of Changes

Upstream version change

Verification

kubectl --version

Linked Issues

• Cut 1.23.0+k3s1 #4689

User-Facing Change

Move containerd out to separate binary
Update Kubernetes to v1.23.1

Further Comments

[dweomer]

Would like to see the split out of containerd as a separate binary in its own PR (that gets merged before this kind of bump).

[dereknola]

LGTM

[olljanat]

I understand that separate binary is needed because opentelemetry but is containerd 1.6.0 release really so far that K3s 1.23 versions cannot wait that?

I was hoping that we would be able to solve #4545 on 1.23 and I assume that other RKE2 users would like to see it too.

[brandond]

containerd v1.6.0 isn't out yet; I have no idea what their target date is for releasing that. Even if it did come out today, we would probably be somewhat reluctant to ship a .0 release.

[dweomer]

• The k3s-root bump should be in a separate PR. I want to see it as a standalone change in the git log as well as tested end-to-end on its own.
• The containerd split should be in a separate PR that includes an ADR. As with k3s-root, I want to see it as a standalone change in the git log as well as tested end-to-end on its own.

[brandond]

• The k3s-root bump should be in a separate PR. I want to see it as a standalone change in the git log as well as tested end-to-end on its own.
• The containerd split should be in a separate PR that includes an ADR. As with k3s-root, I want to see it as a standalone change in the git log as well as tested end-to-end on its own.

Sorry, I thought based on our conversation in standup the other day that we were OK not doing these separately since no-one else cared to see them split out. I can take a moment to create additional PRs for those, but since they are required to successfully build 1.23, I will also leave those commits here and then rebase on top of the merged versions once they're in.

[Oats87]

LGTM; should we torch the vendor directory ....?

[Oats87]

yay for moving packages

[Oats87]

We should definitely make sure to get this into our other branches

[dweomer]

LGTM (assuming the cri-tools mismatch is on purpose and will be dealt with via follow-on PR)