-
Notifications
You must be signed in to change notification settings - Fork 41.1k
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
kubectl-debug: add more debugging profiles #110526
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: knight42 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 |
/cc @verb |
@knight42: The following test failed, say
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. |
/assign |
@verb Hi! Would you like to have an early review to see if I was on the right track? |
@knight42 sure thing, this is next on my list. |
There was a problem hiding this 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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
- Creating a copy of the pod. This should strip labels & probes.
- 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. |
There was a problem hiding this comment.
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.
Signed-off-by: Jian Zeng <[email protected]>
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]>
Signed-off-by: Jian Zeng <[email protected]>
Signed-off-by: Jian Zeng <[email protected]>
d26fc86
to
c4a8795
Compare
@knight42 are you still working on this? |
It is strange that I cannot reply directly to the comment..
I think we already did it. If the debug container is found in kubernetes/staging/src/k8s.io/kubectl/pkg/cmd/debug/debug.go Lines 607 to 614 in 79a62d6
If the debug container is found in |
@verb I am still working on it though I might be slow to respond recently due to the busy work 😢 |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
@knight42 - are you still working on this ? I'm looking to use the |
Hi, I am unavilable to work on this recently, please feel free to take it. |
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?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: