KEP 1441 - kubectl debug

[soltysh]

Enhancement Description

• One-line enhancement description (can be used as a release note): Add a new command to debug pods.
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/1441-kubectl-debug
• Discussion Link: sig-cli agenda
• Primary contact (assignee): @verb, @ardaguclu, @soltysh
• Responsible SIGs: sig-cli
• Enhancement target (which target equals to which milestone):
  • Alpha release target 1.18
  • Beta release target 1.20
  • Stable release target (?)

[soltysh]

/stage alpha
/kind feature
/sig cli
/milestone v1.18

[jeremyrickard]

Hey there @soltysh can you confirm that this will be in the 1.18 release? To make it into the release, the KEP will need to be merged as implementablewith a Test Plan (looks like that's a TODO) by enhancements freeze, which is going to be end of day (pacific time) on January 28th

[soltysh]

@jeremyrickard yup, I confirm. The KEP should be merged later today after SIG-CLI call, then we'll start with the implementation right away.

[jeremyrickard]

Thanks for getting the KEP in @soltysh 🎊

[palnabarun]

Updated the issue description with KEP link.

[VineethReddy02]

Hello, @soltysh, I'm 1.18 docs lead.
Does this enhancement work planned for 1.18 require any new docs (or modifications to existing docs)? If not, can you please update the 1.18 Enhancement Tracker Sheet (or let me know and I'll do so)
If so, just a friendly reminder we're looking for a PR against k/website (branch dev-1.18) due by Friday, Feb 28th, it can just be a placeholder PR at this time. Let me know if you have any questions!

[verb]

@VineethReddy02 ack, this will include doc updates and we will open a placeholder PR by Feb 28. Thanks!

[helayoty]

Hi @soltysh @verb We're only a few days out from code freeze now. It does not look like your PRs have merged yet, are you still feeling like you're on track for code freeze for this enhancement? Do you want to defer this to 1.19 based on the reviewer bandwidth? Or try and make a push?

[verb]

@helayoty I expect this to merge in time.

[3k8]

Add support for override image command & args for debug some error between container starting？
such as

kubectl run nginx --image nginx --debug
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        command: ["sleep"]
        args: ["1d"]
        resources: {}

[verb]

@cnk8s This is indeed included in the proposal. See Pod Troubleshooting by Copy

[verb]

@aylei Are you interested in working on Pod Troubleshooting by Copy for 1.19? or anything else related to debug?

[aylei]

@verb Absolutely

[aylei]

I will draft a PR this week

[zanetworker]

@verb reading the KEP, I still don't get how pod-troubleshooting by copy would work, what does copy mean in this case?

[verb]

@chrisnegus 👋 I opened kubernetes/website#32265 as a 1.24 placeholder.

[gracenng]

Hi @verb 1.24 Enhancements Team here,
With Code Freeze approaching on 18:00 PDT Tuesday March 29th 2022, the enhancement status is at risk as there is no linked k/k PR. Kindly list them in this issue. Thanks!

(Update)
Open Implementation k/k PR:

• refactor(kubectl): add ProfileApplier interface for kubectl-debug kubernetes#105008

[katcosgrove]

Hey y'all! We're approaching last call for feature blogs, as the freeze is Wednesday, March 23. If you would like to have a feature blog for this, please add it to the tracking sheet and reach out to me if you have any questions. Thank you!

[verb]

Hi @gracenng, We didn't get this finished in time. Let's please slip this to 1.25. Thanks!

[verb]

Hi @parul5sahoo @soltysh 👋

We're going to be working on this in the 1.25 cycle, but it will not be graduating. Do we need to add it to the v1.25 milestone?

Thanks!

[soltysh]

Given that we're not going to promote this, but rather still keep it as beta I don't see a reason for update to the KEP.

[tonyaw]

@verb, from issue kubernetes/kubernetes#110126, I realized the suggested way to "bypassing security policy" is done by "usernames" configured by "exemptions".
I suggest to add related description into the KEP to avoid confusion.

[sftim]

It looks like this feature moved to beta in v1.22 with docs apparently missing (see kubernetes/website#32265)

SIG CLI folks, please consider adding a good level of docs coverage before this graduates to stable.

[soltysh]

SIG CLI folks, please consider adding a good level of docs coverage before this graduates to stable.

@verb can you make sure this is addressed?

[verb]

It looks like this feature moved to beta in v1.22 with docs apparently missing (see kubernetes/website#32265)

@sftim @soltysh kubectl debug moved to beta in 1.20 (not 1.22) by kubernetes/kubernetes#96138. I updated the docs for 1.20 in kubernetes/website#24847.

The PR you linked (kubernetes/website#32265) is for 1.24, but we didn't end up merging any changes in 1.24 so I let the PR expire.

SIG CLI folks, please consider adding a good level of docs coverage before this graduates to stable.

I'm motivated to write docs, but it's hard for me to know what SIG Docs considers a good level of coverage. I'm happy to add items to the graduation criteria if you have guidance for deliverables (e.g. add a new troubleshooting doc, split the existing pod troubleshooting doc) otherwise I'll try to figure it out when the time comes and reach out if it's non-trivial.

[sftim]

kubernetes/website#35031 is the main piece that I think is missing.

[k8s-triage-robot]

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-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.

[verb]

Let's reopen this since development has picked up again. I think we should finish implementing debug profiles, mark kubectl debug as stable and then improve it with future KEPs. wdyt @ardaguclu?

/reopen
/remove-lifecycle rotten

[k8s-ci-robot]

@verb: Reopened this issue.

In response to this:

Let's reopen this since development has picked up again. I think we should finish implementing debug profiles, mark kubectl debug as stable and then improve it with future KEPs. wdyt @ardaguclu?

/reopen
/remove-lifecycle rotten

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.

[aecay]

@verb I have a question (and I hope this is the right place to raise it). Specifically it relates to the netadmin debugging profile from the KEP. This is specified and implemented (link) to only add the CAP_NET_ADMIN capability to the debugging pod. However, there are a variety of useful programs for network debugging that require CAP_NET_RAW in addition to NET_ADMIN. (Two examples that spring to mind are tcpdump and mtr).

In line with the goal of the netadmin profile "This profile offers elevated privileges for network debugging." I wonder if it would be possible to modify the spec (and implementation) to also include NET_RAW in the netadmin profile. Thanks 🙂