Skip to content

OpenCensus tracing support added to Kubelet #1

Open
Monkeyanator wants to merge 2 commits intomaster-freezefrom
opencensus-tracing
Open

OpenCensus tracing support added to Kubelet #1
Monkeyanator wants to merge 2 commits intomaster-freezefrom
opencensus-tracing

Conversation

@Monkeyanator
Copy link
Owner

@Monkeyanator Monkeyanator commented Oct 3, 2018

What this PR does / why we need it:

This PR introduces a proof of concept implementation for tracing internal components of Kubernetes with OpenCensus. This small sample constructs a somewhat arbitrary trace from the syncPod routine of the Kubelet, tags the trace with the host being run on, and annotates various events within the syncPod routine.

While the implementation in the PR is limited to Stackdriver, the use of OpenCensus makes it trivial to port these traces to Zipkin, Jaeger, or various other supported backends.

The traces for the Kubelet, in their current state, look as follows:

kubelet-trace

These traces are can be queried per node, or per latency percentile. Stackdriver provides the following useful view which could prove useful in diagnosing common causes for high latency:

latency-distro

Which issue(s) this PR fixes

There have been various issues related to the need for tracing within Kubernetes components:

kubernetes#26507
kubernetes#8806
kubernetes#815

Special notes for your reviewer:

Had to make version changes to protobuf and oauth to make the newly added dependencies work; this PR is more of a sample than something to be merged at the moment.

@Monkeyanator Monkeyanator changed the title Opencensus tracing OpenCensus tracing support added to Kubelet Oct 3, 2018
Copy link

@dashpole dashpole left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a couple of nits, and a question about how to deal with spans that don't actually "do" anything.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use kl.nodeName here instead of getting it from the os

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit (means a small change that doesn't block lgtm): no spaces between error generating functions and error handling

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this belong inside or outside the if updateType == kubetypes.SyncPodKill { statement? I.E. is it permissible to skip a child span entirely if it isn't a kill pod operation?

If my pod doesn't use any volumes, will I still get a tiny span that says "Mounting Volumes"? That would be confusing to me if I didn't know how this was implemented.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great point, definitely would be confusing to get a tiny irrelevant span. My thought process was that there might be some logic associated with deciding whether various processes should be carried out (determining whether volume needs mounting, determining whether some pod should be killed) that might be useful to trace, but probably not in this case.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: generally, only modify lines where you are making code changes. Also, compare diffs yourself before sending them as a PR.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same question about span being inside the if statement

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and all the other ones below as well.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: unneccessary comment

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of producing a new context, can we overrwrite the ctx variable each time? That would make the code less brittle, and easier to add new spans if we need to in the future.

@dashpole
Copy link

dashpole commented Oct 3, 2018

minor note, but it looks like you didn't regenerate the dependency Licenses. Should be some script in /hack

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just tracing the creation of the kubernetes event, which probably isn't useful. I would probably remove this altogether, or put the tracing within the networkErrors() function.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or rather, it doesn't need to be in the function, but around it here.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this still work if we don't overwrite the ctx? Previously, you passed the context returned from the StartSpan for kill pod to the next StartSpan call.

Copy link
Owner Author

@Monkeyanator Monkeyanator Oct 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, since we return no matter what at the end of this block, I believe we can just use the existing context to begin the span and don't need to redefine ctx

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, ok. Sounds good

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, this is just tracing the creation of the event. It needs to be around the makePodDataDirs function.

@dashpole
Copy link

dashpole commented Oct 4, 2018

ok, this LGTM. Can you squash your commits down to two? I.E. one with all of the godep and license changes, and one with the code changes.

For documentation purposes (and so you can link it for people who ask), adding a screenshot or two of what these traces look like in stackdriver would also be helpful.

// if we want to kill a pod, do it now!
if updateType == kubetypes.SyncPodKill {

_, podKillSpan := trace.StartSpan(ctx, "Pod kill logic")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't use regular sentences as span names.

Span names are statistically interesting identifier to represent a task.

For example,

_, podKillSpan := trace.StartSpan(ctx, "kubernetes.podkill")

would be a better fit. The comment applies to all the spans.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the right way to construct a span name.

// if we want to kill a pod, do it now!
if updateType == kubetypes.SyncPodKill {

_, podKillSpan := trace.StartSpan(ctx, "Pod kill logic")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the right way to construct a span name.

kl.recorder.Eventf(pod, v1.EventTypeWarning, events.NetworkNotReady, "%s: %v", NetworkNotReadyErrorMsg, rs)
return fmt.Errorf("%s: %v", NetworkNotReadyErrorMsg, rs)
}
networkConditionSpan.End()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably here you need the ctx to also revert the context to the previous value, otherwise the next span cgroupSpan will be a child of the networkConditionSpan. Same everywhere you have this problem.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants