kubectl debug状态为CrashLoopBackOff的Pod报错 about kubectl-debug HOT 8 OPEN

查看target Pod状态为PodFitsHostPorts
kubectl describe pod日志
Status: Failed
Reason: PodFitsHostPorts
Message: Pod Predicate PodFitsHostPorts failed

from kubectl-debug.

The problem is that the forked pod ran to COMPLETE status instead of RUNNING.

How many containers in the target Pod?

from kubectl-debug.

查看target Pod状态为PodFitsHostPorts
kubectl describe pod日志
Status: Failed
Reason: PodFitsHostPorts
Message: Pod Predicate PodFitsHostPorts failed

That make sense:

1. The original pod (target pod) uses the host network, so does the forked pod;
2. The forked pod is explicitly assigned to the same node of original pod in favor of environment consistency;
3. The forked pod cannot run in the target node due to the collision of host port.

from kubectl-debug.

The problem is that the forked pod ran to COMPLETE status instead of RUNNING.

How many containers in the target Pod?

The problem is that the pod state of CrashLoopBackOff is definitely not possible to Running。
Our goal is not to find the reason for the CrashLoopBackOff state?

from kubectl-debug.

@kerven88
Yes, of course the goal is to find the reason of the CrashLoopBackOff state.

However, the strategy kubectl-debug take is to fork a Pod and reproduce the issue in the new Pod. The command of the new Pod will be replaced so the new Pod won't crash on start. This works in some scenarios but fails for specific scenarios like this.

As for this issue, the problems of the new Pod and the old Pod (target Pod) are actually different:

• The old Pod crash for some reason on start, where we want to find the reason;
• The new Pod cannot run in the target host because the host port has been used by the old Pod, so we cannot proceed on to reproduce the crash at the start time;

HostNetwork should be special case and kubectl-debug should have change the port of new Pod.

from kubectl-debug.

@kerven88
Yes, of course the goal is to find the reason of the CrashLoopBackOff state.

However, the strategy kubectl-debug take is to fork a Pod and reproduce the issue in the new Pod. The command of the new Pod will be replaced so the new Pod won't crash on start. This works in some scenarios but fails for specific scenarios like this.

As for this issue, the problems of the new Pod and the old Pod (target Pod) are actually different:

• The old Pod crash for some reason on start, where we want to find the reason;
• The new Pod cannot run in the target host because the host port has been used by the old Pod, so we cannot proceed on to reproduce the crash at the start time;

HostNetwork should be special case and kubectl-debug should have change the port of new Pod.

That's right, how can I customize the port number of the new Pod?

from kubectl-debug.

@kerven88 This requires modification of code, hopefully I will submit a PR this weekend, or I can give some guidance if you are willing to work on this.

from kubectl-debug.

@kerven88 This requires modification of code, hopefully I will submit a PR this weekend, or I can give some guidance if you are willing to work on this.

Tks! Looking forward to your PR submitsion。

from kubectl-debug.