Skip to content
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.

Sign up for GitHub

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

Propose a feature to troubleshoot running pods #649

Merged
merged 6 commits into from
Sep 27, 2017
+743 −0
Merged

Propose a feature to troubleshoot running pods #649

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
fae75ad
Propose a feature to troubleshoot running pods
verb Dec 21, 2016
127550e
Address feedback in pod troubleshooting proposal
verb May 30, 2017
33a5520
Add analysis of standalone pod alternative
verb Jun 23, 2017
bcd232f
Switch Pod Troubleshooting API back to /exec
verb Sep 6, 2017
8136e3d
Move Pod Troubleshooting proposal into node subdir
verb Sep 25, 2017
473c49d
Name PodExecOptions fields as recommended by API reviewer
verb Sep 27, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add analysis of standalone pod alternative
  • Loading branch information
@verb
verb committed Sep 25, 2017
commit 33a5520e0b6de4b4de7368668bb9de609c46c1c8
29 changes: 23 additions & 6 deletions contributors/design-proposals/troubleshoot-running-pods.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -618,12 +618,29 @@ undesirable.

#### Standalone Pod in Shared Namespace

Kubernetes could support starting a standalone pod that shares the namespace of
an existing pod.

This would be a small change to Kubernetes, but it would create edge cases in
the pod lifecycle that would have to be considered. For example, what happens to
the debugging pod when the target pod is destroyed?
Rather than inserting a new container into a pod namespace, Kubernetes could
instead support creating a new pod with container namespaces shared with
another, target pod. This would be a simpler change to the Kubernetes API, which
would only need a new field in the pod spec to specify the target pod. To be
useful, the containers in this "Debug Pod" should be run inside the namespaces
(network, pid, etc) of the target pod but remain in a separate resource group
(e.g. cgroup for container-based runtimes).

This would be a rather fundamental change to pod, which is currently treated as
an atomic unit. The Container Runtime Interface has no provisions for sharing
outside of a pod sandbox and would need a refactor. This could be a complicated
change for non-container runtimes (e.g. hypervisor runtimes) which have more
rigid boundaries between pods.

Effectively, Debug Pod must be implemented by the runtimes while Debug
Containers are implemented by the kubelet. Minimizing change to the Kubernetes
API is not worth the increased complexity for the kubelet and runtimes.

It could also be possible to implement a Debug Pod as a privileged pod that runs
in the host namespace and interacts with the runtime directly to run a new
container in the appropriate namespace. This solution would be runtime-specific
and effectively pushes the complexity of debugging to the user. Additionally,
requiring node-level access to debug a pod does not meet our requirements.

#### Exec from Node

Expand Down