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.

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

CRI: Debug API #53757

Closed
Random-Liu opened this Issue Oct 12, 2017 · 7 comments

Comments

Projects
None yet
8 participants
@Random-Liu
Member

Random-Liu commented Oct 12, 2017

Today, CRI only provides information needed by Kubelet.

But actually, Kubelet is not the only consumer of CRI. crilctl, which is a CLI tool for debugging purpose, also talks with CRI to get debug information for user.

Most operations provided in crictl are well covered by CRI already. The only thing missing is detailed debug information about container, sandbox, image and container runtime itself (think about docker inspect and docker info). For linux container based container runtime, it could be Pid, Namespaces, Container Config etc.

Since we want crictl to be portable across different CRI container runtimes, it has to get the debug information from CRI instead of from the underlying container runtime directly.

Ideally,

  • Each container runtime should be able to provide runtime specific debug information via CRI.
  • Kubelet should never consume that information.
  • crictl should easily format and print the debug information to user.

The debug information could just be a string in json format, which could be easily combined, converted and printed.

As for how to expose the debug information through CRI, there are several options:

  • Option 1: Add a ContainerInfo field in ContainerStatusResponse, and also corresponding fields in PodSandboxStatusResponse, ImageStatusResponse and StatusResponse. The ContainerInfo is just a string in json format.
    • Pros: Won't break existing CRI container runtime. If they don't want to provide this, they could just return empty.
    • Cons: This introduces extra overhead in each status call, the extra encoding/decoding in grpc will be a pain. And the more debug information a container runtime provides, the worse its performance is, which doesn't seem like an encouragement to more debug info.
  • Option 2 (Preferred): Same with Option 1, but add a Debug bool option in ContainerStatusRequest, and also other status requests. Container runtime should only provide extra debug information when Debug=true.
    • Pros: Extra debug information doesn't add extra performance overhead in production.
    • Cons: The Debug option may be confusing to people, we may need another name.
  • Option 3: Add separate CRI functions for the debug information.
    • Pros: More clear.
    • Cons: All CRI runtimes need to support these functions, at least need to return not implemented for those functions.
  • Option 4: Separate CRI debug API. crictl should only use it when it is present, and just use CRI if it isn't.
    • Pros: Clean. The original CRI won't be affected at all.
    • Cons: More complex than option 2.

I personally prefer option 2, but am open to other options. :)

@yujuhong @feiskyer @mikebrow @abhi @mrunalp @runcom
/cc @dchen1107
/cc @kubernetes/sig-node-api-reviews

@feiskyer

This comment has been minimized.

Show comment
Hide comment
@feiskyer

feiskyer Oct 12, 2017

Member

+1 for the proposal. detailed information could help a lot for validating cri-compatible runtimes and debugging container problems.

Option 2 also seems good to me, and it doesn't break kuberuntime since debug should be false by default. I suggest rename Debug to Verbose, which I think is more clear.

Member

feiskyer commented Oct 12, 2017

+1 for the proposal. detailed information could help a lot for validating cri-compatible runtimes and debugging container problems.

Option 2 also seems good to me, and it doesn't break kuberuntime since debug should be false by default. I suggest rename Debug to Verbose, which I think is more clear.

@WIZARD-CXY

This comment has been minimized.

Show comment
Hide comment
@WIZARD-CXY

WIZARD-CXY Oct 12, 2017

Contributor

agreed with @feiskyer

Contributor

WIZARD-CXY commented Oct 12, 2017

agreed with @feiskyer

@runcom

This comment has been minimized.

Show comment
Hide comment
@runcom

runcom Oct 12, 2017

Member

+1 on option 2 and +1 for Verbose

Member

runcom commented Oct 12, 2017

+1 on option 2 and +1 for Verbose

@yujuhong

This comment has been minimized.

Show comment
Hide comment
@yujuhong

yujuhong Oct 12, 2017

Contributor

Verbose sounds better.

Contributor

yujuhong commented Oct 12, 2017

Verbose sounds better.

@abhi

This comment has been minimized.

Show comment
Hide comment
@abhi

abhi Oct 12, 2017

Member

+1 on verbose
+1 on Option 2

Member

abhi commented Oct 12, 2017

+1 on verbose
+1 on Option 2

@Random-Liu

This comment has been minimized.

Show comment
Hide comment
@Random-Liu

Random-Liu Oct 12, 2017

Member

Cool, it seems that everyone is fine with Option 2 + Verbose.
I'll send out a PR then. :)

Thanks for providing suggestions!

Member

Random-Liu commented Oct 12, 2017

Cool, it seems that everyone is fine with Option 2 + Verbose.
I'll send out a PR then. :)

Thanks for providing suggestions!

@k8s-merge-robot

This comment has been minimized.

Show comment
Hide comment
@k8s-merge-robot

k8s-merge-robot Oct 15, 2017

Contributor

[MILESTONENOTIFIER] Milestone Removed

@Random-Liu

Important: This issue was missing labels required for the v1.9 milestone for more than 3 days:

kind: Must specify exactly one of kind/bug, kind/cleanup or kind/feature.

Help
Contributor

k8s-merge-robot commented Oct 15, 2017

[MILESTONENOTIFIER] Milestone Removed

@Random-Liu

Important: This issue was missing labels required for the v1.9 milestone for more than 3 days:

kind: Must specify exactly one of kind/bug, kind/cleanup or kind/feature.

Help

@k8s-merge-robot k8s-merge-robot removed this from the v1.9 milestone Oct 15, 2017

@Random-Liu Random-Liu removed the kind/bug label Oct 16, 2017

k8s-merge-robot added a commit that referenced this issue Oct 18, 2017

Merge pull request #53965 from Random-Liu/add-extra-info-in-cri
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

CRI: Add extra information in status functions in CRI.

Fixes #53757.

@yujuhong @feiskyer @mrunalp 
/cc @kubernetes/sig-node-api-reviews 

```release-note
Verbose option is added to each status function in CRI. Container runtime could return extra information in status response for debugging.
```

@mikebrow mikebrow referenced this issue Oct 30, 2017

Closed

Implement CRI Debug API #359

4 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment