correct way to use kubernetes watches
I am new to Kubernetes and I am not really sure on how to proceed to implement correctly a watch; especially I am not sure on how to deal with the resourceVersion parameter.
The goal is to watch for new pods with a specific label, and in case of error or disconnection from the cluster being able to restart the watch from the last event occurred.
I am doing something like this:
// after setting up the connection and some parameters
String lastResourceVersion = null; // at beginning version is unknown
while (true) {
try {
Watch<V1Pod> watcher = Watch.createWatch(
client,
api.listNamespacedPodCall(namespace, pretty, fieldSelector, labelSelector, lastResourceVersion, forEver, true, null, null),
new TypeToken<Watch.Response<V1Pod>>() {}.getType()
);
for (Watch.Response<V1Pod> item : watcher) {
//increment the version
lastResourceVersion = item.object.getMetadata().getResourceVersion();
// do some stuff with the pod
}
} catch (ApiException apiException) {
log.error("restarting the watch from "+lastResourceVersion, apiException);
}
}
Is it correct to use the resourceVersion of a Pod to reinitialize the watch call? Is this number a kind of timestamp for all the events in the cluster, or different api will use different sequences?
Do I need to watch for specific exceptions? eg. in case of the resourceVersion is to old?
thanks
kubernetes watch
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
add a comment |
I am new to Kubernetes and I am not really sure on how to proceed to implement correctly a watch; especially I am not sure on how to deal with the resourceVersion parameter.
The goal is to watch for new pods with a specific label, and in case of error or disconnection from the cluster being able to restart the watch from the last event occurred.
I am doing something like this:
// after setting up the connection and some parameters
String lastResourceVersion = null; // at beginning version is unknown
while (true) {
try {
Watch<V1Pod> watcher = Watch.createWatch(
client,
api.listNamespacedPodCall(namespace, pretty, fieldSelector, labelSelector, lastResourceVersion, forEver, true, null, null),
new TypeToken<Watch.Response<V1Pod>>() {}.getType()
);
for (Watch.Response<V1Pod> item : watcher) {
//increment the version
lastResourceVersion = item.object.getMetadata().getResourceVersion();
// do some stuff with the pod
}
} catch (ApiException apiException) {
log.error("restarting the watch from "+lastResourceVersion, apiException);
}
}
Is it correct to use the resourceVersion of a Pod to reinitialize the watch call? Is this number a kind of timestamp for all the events in the cluster, or different api will use different sequences?
Do I need to watch for specific exceptions? eg. in case of the resourceVersion is to old?
thanks
kubernetes watch
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
2
I am not familiar with cpp or java implementation of the watch functionality, but in general, you need to get/list resource and use its resourceVersion to setup a watch. Resource version itself is a numberthat corresponds to version of resource in etcd and is used to determine if there were any changes to the resource. Regarding your second point, yes you should catch exception if the resource version is too old. You can read more here: kubernetes.io/docs/reference/using-api/api-concepts/…
– Adam Otto
Nov 9 '18 at 14:02
And here is an example of implementing list and watch and handle all possible exceptions in go (if you know cpp, it should be easy for you to undestand it) github.com/kubernetes/client-go/blob/master/tools/cache/…
– Adam Otto
Nov 9 '18 at 14:05
add a comment |
I am new to Kubernetes and I am not really sure on how to proceed to implement correctly a watch; especially I am not sure on how to deal with the resourceVersion parameter.
The goal is to watch for new pods with a specific label, and in case of error or disconnection from the cluster being able to restart the watch from the last event occurred.
I am doing something like this:
// after setting up the connection and some parameters
String lastResourceVersion = null; // at beginning version is unknown
while (true) {
try {
Watch<V1Pod> watcher = Watch.createWatch(
client,
api.listNamespacedPodCall(namespace, pretty, fieldSelector, labelSelector, lastResourceVersion, forEver, true, null, null),
new TypeToken<Watch.Response<V1Pod>>() {}.getType()
);
for (Watch.Response<V1Pod> item : watcher) {
//increment the version
lastResourceVersion = item.object.getMetadata().getResourceVersion();
// do some stuff with the pod
}
} catch (ApiException apiException) {
log.error("restarting the watch from "+lastResourceVersion, apiException);
}
}
Is it correct to use the resourceVersion of a Pod to reinitialize the watch call? Is this number a kind of timestamp for all the events in the cluster, or different api will use different sequences?
Do I need to watch for specific exceptions? eg. in case of the resourceVersion is to old?
thanks
kubernetes watch
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
I am new to Kubernetes and I am not really sure on how to proceed to implement correctly a watch; especially I am not sure on how to deal with the resourceVersion parameter.
The goal is to watch for new pods with a specific label, and in case of error or disconnection from the cluster being able to restart the watch from the last event occurred.
I am doing something like this:
// after setting up the connection and some parameters
String lastResourceVersion = null; // at beginning version is unknown
while (true) {
try {
Watch<V1Pod> watcher = Watch.createWatch(
client,
api.listNamespacedPodCall(namespace, pretty, fieldSelector, labelSelector, lastResourceVersion, forEver, true, null, null),
new TypeToken<Watch.Response<V1Pod>>() {}.getType()
);
for (Watch.Response<V1Pod> item : watcher) {
//increment the version
lastResourceVersion = item.object.getMetadata().getResourceVersion();
// do some stuff with the pod
}
} catch (ApiException apiException) {
log.error("restarting the watch from "+lastResourceVersion, apiException);
}
}
Is it correct to use the resourceVersion of a Pod to reinitialize the watch call? Is this number a kind of timestamp for all the events in the cluster, or different api will use different sequences?
Do I need to watch for specific exceptions? eg. in case of the resourceVersion is to old?
thanks
kubernetes watch
kubernetes watch
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
asked Oct 9 '18 at 9:20
G. BricconiG. Bricconi
462
462
2
I am not familiar with cpp or java implementation of the watch functionality, but in general, you need to get/list resource and use its resourceVersion to setup a watch. Resource version itself is a numberthat corresponds to version of resource in etcd and is used to determine if there were any changes to the resource. Regarding your second point, yes you should catch exception if the resource version is too old. You can read more here: kubernetes.io/docs/reference/using-api/api-concepts/…
– Adam Otto
Nov 9 '18 at 14:02
And here is an example of implementing list and watch and handle all possible exceptions in go (if you know cpp, it should be easy for you to undestand it) github.com/kubernetes/client-go/blob/master/tools/cache/…
– Adam Otto
Nov 9 '18 at 14:05
add a comment |
2
I am not familiar with cpp or java implementation of the watch functionality, but in general, you need to get/list resource and use its resourceVersion to setup a watch. Resource version itself is a numberthat corresponds to version of resource in etcd and is used to determine if there were any changes to the resource. Regarding your second point, yes you should catch exception if the resource version is too old. You can read more here: kubernetes.io/docs/reference/using-api/api-concepts/…
– Adam Otto
Nov 9 '18 at 14:02
And here is an example of implementing list and watch and handle all possible exceptions in go (if you know cpp, it should be easy for you to undestand it) github.com/kubernetes/client-go/blob/master/tools/cache/…
– Adam Otto
Nov 9 '18 at 14:05
2
2
I am not familiar with cpp or java implementation of the watch functionality, but in general, you need to get/list resource and use its resourceVersion to setup a watch. Resource version itself is a numberthat corresponds to version of resource in etcd and is used to determine if there were any changes to the resource. Regarding your second point, yes you should catch exception if the resource version is too old. You can read more here: kubernetes.io/docs/reference/using-api/api-concepts/…
– Adam Otto
Nov 9 '18 at 14:02
I am not familiar with cpp or java implementation of the watch functionality, but in general, you need to get/list resource and use its resourceVersion to setup a watch. Resource version itself is a numberthat corresponds to version of resource in etcd and is used to determine if there were any changes to the resource. Regarding your second point, yes you should catch exception if the resource version is too old. You can read more here: kubernetes.io/docs/reference/using-api/api-concepts/…
– Adam Otto
Nov 9 '18 at 14:02
And here is an example of implementing list and watch and handle all possible exceptions in go (if you know cpp, it should be easy for you to undestand it) github.com/kubernetes/client-go/blob/master/tools/cache/…
– Adam Otto
Nov 9 '18 at 14:05
And here is an example of implementing list and watch and handle all possible exceptions in go (if you know cpp, it should be easy for you to undestand it) github.com/kubernetes/client-go/blob/master/tools/cache/…
– Adam Otto
Nov 9 '18 at 14:05
add a comment |
1 Answer
1
active
oldest
votes
Adam is right.
This is best explained by https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
Quoting relevant parts (emphasis mine):
When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a resourceVersion value that can be used to initiate a watch against the server.
... snip ...
When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a list operation, and starting the watch from the resourceVersion returned by that new list operation.
So before you call watch, you should list and pull the resourceVersion from the list (not the objects inside of it). Then start the watch with that resourceVersion. If the watch fails for some reason, you will have to list again and then use the resourceVersion from that list to re-establish the watch.
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52717497%2fcorrect-way-to-use-kubernetes-watches%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Adam is right.
This is best explained by https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
Quoting relevant parts (emphasis mine):
When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a resourceVersion value that can be used to initiate a watch against the server.
... snip ...
When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a list operation, and starting the watch from the resourceVersion returned by that new list operation.
So before you call watch, you should list and pull the resourceVersion from the list (not the objects inside of it). Then start the watch with that resourceVersion. If the watch fails for some reason, you will have to list again and then use the resourceVersion from that list to re-establish the watch.
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
add a comment |
Adam is right.
This is best explained by https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
Quoting relevant parts (emphasis mine):
When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a resourceVersion value that can be used to initiate a watch against the server.
... snip ...
When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a list operation, and starting the watch from the resourceVersion returned by that new list operation.
So before you call watch, you should list and pull the resourceVersion from the list (not the objects inside of it). Then start the watch with that resourceVersion. If the watch fails for some reason, you will have to list again and then use the resourceVersion from that list to re-establish the watch.
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
add a comment |
Adam is right.
This is best explained by https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
Quoting relevant parts (emphasis mine):
When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a resourceVersion value that can be used to initiate a watch against the server.
... snip ...
When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a list operation, and starting the watch from the resourceVersion returned by that new list operation.
So before you call watch, you should list and pull the resourceVersion from the list (not the objects inside of it). Then start the watch with that resourceVersion. If the watch fails for some reason, you will have to list again and then use the resourceVersion from that list to re-establish the watch.
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
Adam is right.
This is best explained by https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
Quoting relevant parts (emphasis mine):
When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a resourceVersion value that can be used to initiate a watch against the server.
... snip ...
When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a list operation, and starting the watch from the resourceVersion returned by that new list operation.
So before you call watch, you should list and pull the resourceVersion from the list (not the objects inside of it). Then start the watch with that resourceVersion. If the watch fails for some reason, you will have to list again and then use the resourceVersion from that list to re-establish the watch.
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
answered Nov 13 '18 at 4:09
krouseykrousey
1,2381219
1,2381219
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52717497%2fcorrect-way-to-use-kubernetes-watches%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I am not familiar with cpp or java implementation of the watch functionality, but in general, you need to get/list resource and use its resourceVersion to setup a watch. Resource version itself is a numberthat corresponds to version of resource in etcd and is used to determine if there were any changes to the resource. Regarding your second point, yes you should catch exception if the resource version is too old. You can read more here: kubernetes.io/docs/reference/using-api/api-concepts/…
– Adam Otto
Nov 9 '18 at 14:02
And here is an example of implementing list and watch and handle all possible exceptions in go (if you know cpp, it should be easy for you to undestand it) github.com/kubernetes/client-go/blob/master/tools/cache/…
– Adam Otto
Nov 9 '18 at 14:05