Skip to content

kubectl-debug: add more debugging profiles #110526

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

knight42
Copy link
Member

@knight42 knight42 commented Jun 12, 2022

What type of PR is this?

/kind feature

What this PR does / why we need it:

Which issue(s) this PR fixes:

xref kubernetes/kubectl#1108

Special notes for your reviewer:

I plan to implement all the remainging debugging profiles listed in kubernetes/kubectl#1108, but I am afraid that the volume of this PR will be too huge, hence I filed a PR with some basic tests to get early feedback from reviewers. If I was on the right track, I would continue to finish my work.

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[KEP]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/1441-kubectl-debug#debugging-profiles

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-kind Indicates a PR lacks a `kind/foo` label and requires one. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. release-note-none Denotes a PR that doesn't merit a release note. area/kubectl sig/cli Categorizes an issue or PR as relevant to SIG CLI. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jun 12, 2022
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: knight42
To complete the pull request process, please assign apelisse after the PR has been reviewed.
You can assign the PR to them by writing /assign @apelisse in a comment when ready.

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

Needs approval from an approver in each of these files:

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

@knight42
Copy link
Member Author

/cc @verb
/triage accepted
/priority backlog

@k8s-ci-robot k8s-ci-robot requested a review from verb June 12, 2022 13:02
@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. priority/backlog Higher priority than priority/awaiting-more-evidence. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Jun 12, 2022
@k8s-ci-robot
Copy link
Contributor

@knight42: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-kubernetes-e2e-kind d26fc86b153e3b1429d8bdfc822d595f944a1233 link true /test pull-kubernetes-e2e-kind

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

@knight42 knight42 marked this pull request as draft June 12, 2022 14:35
@k8s-ci-robot k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 12, 2022
@verb
Copy link
Contributor

verb commented Jun 13, 2022

/assign

@knight42
Copy link
Member Author

@verb Hi! Would you like to have an early review to see if I was on the right track?

@verb
Copy link
Contributor

verb commented Jul 8, 2022

@knight42 sure thing, this is next on my list.

Copy link
Contributor

@verb verb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this approach is fine. Note that I need to rebuild context about the implementation, so please point out when I've gotten a detail wrong or made a bad assumption.

Is there anything I can do to help with implementation?

}
return applier
}

func TestGenerateDebugContainer(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes more sense to test the new profiles individually in a profiles_test.go

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean we should move TestGenerateDebugContainer, TestGeneratePodCopyWithDebugContainer and TestGenerateNodeDebugPod to the new profiles_test.go?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I meant that we should create a profiles_test.go to test the methods in profiles.go individually, for example TestGeneralProfileApply, TestBaselineProfileApply, etc. My thinking is that we'll want multiple test cases per profile, so the table in debug_test.go would get really long.


func (p *generalProfile) Apply(pod *corev1.Pod, containerName string, target runtime.Object) error {
switch target.(type) {
case *corev1.Pod:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the case of pod we'll want to detect whether pod and target are the same and have different behavior. I don't think we plan on stripping labels for debug by ephemeral container.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm I would like to double check, the proposal https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/1441-kubectl-debug#profile-general says that:

Probes and labels are stripped from Pod copies to ensure the copy isn't killed and doesn't receive traffic during debugging.

Do we need to strip labels?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When debugging a pod, there are two outcomes:

  1. Creating a copy of the pod. This should strip labels & probes.
  2. Adding an ephemeral container to an existing pod. This should not change labels & probes.

I should have been more clear in the KEP. I meant for the section you pasted to apply to "Pod copies" (i.e. the first case above)

continue
}
// For copy of pod: sets SYS_PTRACE in debugging container, sets shareProcessNamespace
// Probes and labels are stripped from Pod copies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want helper routines for the common operations, I think.

knight42 added 4 commits July 14, 2022 21:40
Including `general`, `baseline` and `restricted`.

I plan to add more profiles afterwards, but I'd like to get early
reviews.

Signed-off-by: Jian Zeng <[email protected]>
@verb
Copy link
Contributor

verb commented Jul 27, 2022

@knight42 are you still working on this?

@knight42
Copy link
Member Author

It is strange that I cannot reply directly to the comment..

For the case of pod we'll want to detect whether pod and target are the same and have different behavior.

I think we already did it.

If the debug container is found in pod.Spec.Containers then pod is a copy of the target, then we strip labels and probes(BTW we don't copy labels when generating pod copy.

func (o *DebugOptions) generatePodCopyWithDebugContainer(pod *corev1.Pod) (*corev1.Pod, string, error) {
copied := &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
Name: o.CopyTo,
Namespace: pod.Namespace,
Annotations: pod.Annotations,
},
Spec: *pod.Spec.DeepCopy(),
).

If the debug container is found in pod.Spec.EphemeralContainers, then pod is an existing pod containing the ephermal container. We don't change its labels & probes.

@knight42
Copy link
Member Author

@verb I am still working on it though I might be slow to respond recently due to the busy work 😢

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 26, 2022
@sding3
Copy link
Contributor

sding3 commented Nov 18, 2022

@knight42 - are you still working on this ?

I'm looking to use the kubectl debug profile that this PR adds, and I wish to avoid having to maintain a fork. So if you aren't currently working on this, I can pick this up.

@knight42
Copy link
Member Author

@knight42 - are you still working on this ?

I'm looking to use the kubectl debug profile that this PR adds, and I wish to avoid having to maintain a fork. So if you aren't currently working on this, I can pick this up.

Hi, I am unavilable to work on this recently, please feel free to take it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubectl cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-kind Indicates a PR lacks a `kind/foo` label and requires one. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/backlog Higher priority than priority/awaiting-more-evidence. release-note-none Denotes a PR that doesn't merit a release note. sig/cli Categorizes an issue or PR as relevant to SIG CLI. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants