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.

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

Make kubelet first acknowledge time of a pod as Pod.Status.StartTime. #10066

Merged
merged 1 commit into from Jun 19, 2015

Conversation

dchen1107
Copy link
Member

@dchen1107
Copy link
Member Author

ok to test

@k8s-bot
Copy link

k8s-bot commented Jun 18, 2015

GCE e2e build/test failed for commit 1145e4b.

@@ -1171,7 +1171,9 @@ func (kl *Kubelet) syncPod(pod *api.Pod, mirrorPod *api.Pod, runningPod kubecont
var podStatus api.PodStatus
if updateType == SyncPodCreate {
podStatus = pod.Status
glog.V(3).Infof("Not generating pod status for new pod %v", podFullName)
podStatus.StartTime = &util.Time{start}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think setPodStatus will already set the time if it's unset.

The impact here is extra qps, because we'll send one update for the time stamp and one update for the running in the defer call, but I'm hoping it won't be too bad.

So I actually wanted to do something a little different (just mentioning it here, not sure if you want to do it): Call SetPodStatus here with the actual pod.Status given to this method, and set the StartTime on that pod when we receive the watch notification (https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubelet/config/config.go#L264 is close enough to the entry point). That would help our e2e tests gather latency numbers, but I'm not going to push too hard for it because it might shortchange the activeDeadline feature :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, setPodStatus does set the time if it's unset. The only reason I am doing it here is that I can reuse the initial timestamp: start. Before initializing PodStatus, kubelet does setup for pod, such as mount. Based on my previous experience, mount could be very slow operation taking many minutes under resource pressure, especially with memory.

I did consider to set StartTim on the watch notification initially. But like what you mentioned, I have concern with activeDeadline feature.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good, guess we discussed the rest of it irl

@bprashanth
Copy link
Contributor

LGTM just the one nit, and a little hope that we'll end up doing what i want

@dchen1107
Copy link
Member Author

e2e test failures are flaky tests.

ok to test

@derekwaynecarr
Copy link
Member

@bprashanth - I am fine setting the StartTime when we receive the watch notification because that is literally when the Kubelet became aware of the pod on its host. As a result, I think its the most consistent solution to the spirit of ActiveDeadlineSeconds. The solution presented here is fine as well because it is prior to any docker pull. That last part is critical for us because we are using the feature to time box a pod, which would include pods that cannot be run because image pulls took a long time, etc.

@dchen1107
Copy link
Member Author

ok to test

@k8s-bot
Copy link

k8s-bot commented Jun 19, 2015

GCE e2e build/test passed for commit 1145e4b.

satnam6502 added a commit that referenced this pull request Jun 19, 2015
Make kubelet first acknowledge time of a pod as Pod.Status.StartTime.
@satnam6502 satnam6502 merged commit d06a460 into kubernetes:master Jun 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm "Looks good to me", indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants