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?

[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 🙂

[verb]

@aecay Thanks for bringing this up, I think this was an oversight. I agree that we should add CAP_NET_RAW to netadmin if it unlocks additional network debugging tools. @wedaly @ardaguclu wdyt?

[ardaguclu]

I'm fine adding CAP_NET_RAW into netadmin, two points might need extra attention;

• Would it be backward compatible for the people already relying on current netadmin implementation?
• I think we need to update KEP first for CAP_NET_RAW in netadmin profile because it hasn't been covered in KEP.

@verb I agree with you that would be better to mark kubectl debug as stable to move forward for the new features(e.g. custom profiles)

[verb]

@ardaguclu Agree about custom profiles with a new KEP. I think NET_RAW is more of a bugfix and it would reasonable to amend the existing KEP, which should be quicker than getting a new KEP reviewed.

Since we're adding a capability I think backwards compatibility won't be much of a concern. The only problem would be if there was an admission controller that was only allowing NET_ADMIN and not NET_RAW.

[mochizuki875]

@verb @ardaguclu
Hi, can I try to fix netadmin debugging profile to add NET_RAW?
If OK, I'll create an new issue and start working.

[mochizuki875]

@verb @ardaguclu
I've tried to fix it.
Could you please check it?

kubernetes/kubernetes#118647