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 (x.y): 1.18
  • Beta release target (x.y): 1.20
  • Stable release target (x.y): 1.30
• [ ] Stable
  • [ ] KEP (k/enhancements) update PR(s): https://github.com/kubernetes/enhancements/pull/4408
  • [ ] Code (k/k) update PR(s):
  • [ ] Docs (k/website) update(s):

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

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

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

Thanks for getting the KEP in @soltysh 🎊

Updated the issue description with KEP link.

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!

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

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?

@helayoty I expect this to merge in time.

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: {}

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

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

@verb Absolutely

I will draft a PR this week

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

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

@zanetworker It'll create a copy of a pod with some fields changed, for example changing an image label to that of a debug version or arguments to "bash".

@verb okay thanks for clarifying, then that means it would be residing in different namespaces (e.g., network) that the original containers in the other pod, what are the use-cases for this?

the reason I asked is that based on my understanding one of the important use-cases is network debugging, not sure if troubleshooting by copy would help here. One idea (which is a bit controversial to be honest) is for the copied pod to share the network-namespace with the source pod, we have been doing that so far via having a common sandbox, but if they are on the same machine that is probably doable right? that would probably have dependencies on the CRI as well?

@zanetworker Correct, the copy of a pod would get all new namespaces. To debug inside the same network namespace you would use an ephemeral container in the existing pod. That feature is still in alpha, so it's not available in most clusters, but that's the intended solution.

@verb I understand the feature, I have been using the API for quite sometime in a side project of mine. What I meant was more a version of trouble shooting by copy that share the network namespace from another pod (not the same) but I guess that maybe here is not pace to discuss, can reach out later :)

/milestone clear

(removing this from the v1.18 milestone as that is complete)

Hey there @verb @soltysh -- 1.19 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating in 1.19?

In order to have this part of the release:

1. The KEP PR must be merged in an implementable state
2. The KEP must have test plans
3. The KEP must have graduation criteria.

The current release schedule is:

• Monday, April 13: Week 1 - Release cycle begins
• Tuesday, May 19: Week 6 - Enhancements Freeze
• Thursday, June 25: Week 11 - Code Freeze
• Thursday, July 9: Week 14 - Docs must be completed and reviewed
• Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released

If you do, I'll add it to the 1.19 tracking sheet (http://bit.ly/k8s-1-19-enhancements). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Thanks!

@msedzins We'll keep this alpha for 1.19, thanks!

Thank you for letting me know @verb

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

/remove-lifecycle stale

Hi @verb @soltysh

Enhancements Lead here. Any plans for this in 1.20?

Thanks! Kirsten

Hi @kikisdeliveryservice, we'll be addressing bugs and doing minor cleanups in 1.20, but no graduation.

Hi @kikisdeliveryservice,

There's been a change of plans. After chatting with sig-cli in the last meeting we've decided to pursue graduation to beta in 1.20. (cc @soltysh).

Thanks!

That is correct!