correct way to use kubernetes watches










9















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










share|improve this question

















  • 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















9















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










share|improve this question

















  • 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













9












9








9


2






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










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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












  • 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












1 Answer
1






active

oldest

votes


















2





+50









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.






share|improve this answer






















    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
    );



    );













    draft saved

    draft discarded


















    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









    2





    +50









    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.






    share|improve this answer



























      2





      +50









      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.






      share|improve this answer

























        2





        +50







        2





        +50



        2




        +50





        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 13 '18 at 4:09









        krouseykrousey

        1,2381219




        1,2381219



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            這個網誌中的熱門文章

            How to read a connectionString WITH PROVIDER in .NET Core?

            Node.js Script on GitHub Pages or Amazon S3

            Museum of Modern and Contemporary Art of Trento and Rovereto