Fix slice sharing bug in cgroup manager

[dashpole]

What type of PR is this?
/kind bug

What this PR does / why we need it:
See https://play.golang.org/p/QQOELuf56v8 for an example of what can happen when sharing underlying slices. Slices are only resized when the slice cannot hold the additional elements, and are increased by powers of two. So appending to a slice may or may not create a new slice to hold the input slice.

We just happened to be lucky that the default for --cgroup-root didn't trigger this behavior because getting pod cgroup slices ([]string{"kubepods", "burstable"} -> []string{"kubepods", "burstable", "<pod_uid>"} always triggered a resize of the former slice, as the size goes from 2 -> 4 each time. But when you specify a cgroup root ([]string{"root", "kubepods", "burstable"} -> []string{"root", "kubepods", "burstable", "<pod_uid>"}, the initial slice is already size 4 (because it was constructed by appending to a size 2 slice), and thus does not trigger a resize, and re-uses the parent slice for each child slice. In this way, after appending one pod uid to the QoS cgroup, the second append produces []string{"root", "kubepods", "burstable", "<pod_uid_1>", "<pod_uid_2>"}, which is a slice resize (4->8).

All of this is to say that we should create a new slice and copy the parent into it when we create a new cgroup. I included my reproduction case as a test case to ensure we don't break this in the future.

Which issue(s) this PR fixes:
Fixes #68416

Does this PR introduce a user-facing change?:

Fixes a bug in previous releases where a pod could be placed inside another pod's cgroup when specifying --cgroup-root

cc @sreis @derekwaynecarr @filbranden @dchen1107 @Random-Liu @yujuhong
/assign @derekwaynecarr @Random-Liu

[dashpole]

/sig node
/priority important-soon

[dashpole]

this should have the 1.13 milestone

[Random-Liu]

/lgtm

[feiskyer]

LGTM. Please create a cherry pick PR to branch-1.12 after this.

[dashpole]

/retest

[dashpole]

/retest

[filbranden]

Thanks @dashpole for tracking this one down!

Ugh, what an ugly interface in Golang... Time to write another Golang rant about it...

I have a tiny nitpick, but what you have is definitely fine, so OK to ignore my suggestion.

Cheers,
Filipe

[yujuhong]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dashpole, yujuhong

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:

• pkg/kubelet/cm/OWNERS [yujuhong]

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

[yujuhong]

What supported versions are affected by this bug?

[dashpole]

this affects 1.11 and 1.12

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[pires]

Why wasn't this marked for backport?

[nikopen]

/lgtm
/milestone v1.13

@pires opening cherry picks for 1.11 and 1.12 soon

is 1.10 maybe affected as well? 3 major versions are supported at a time

[pires]

@nikopen according to our testing only 1.11+ is affected.