How Docker Swarm and Kubernetes validate their management choices?











up vote
0
down vote

favorite












Docker Swarm and Kubernetes are two systems to manage applications on several nodes. If a node is draining or its load is very high they start some procedure to maintain the desired state described in the requirements.



Of course, when they manage the application over the infrastructure, they have to take some choices in order to modify the state. How the decisions are taken in order to ensure that the decisions don't damage the system?



I mean, not when the actions are triggered (system analysis) but how can we prove that the decision taken are the best decision to resolve the problem?
There is some documentation on that? I don't find any referring to this topic.



For example:
I have a node which resources are almost free. Then, at a certain moment, their resources became insufficient, and remain insufficient just for a second, then return free. If the manager migrates applications from that node to another one because of that second of insufficient resources has trigged the migration functions, probably it will create more problem than solved ones since the insufficient resources problem are already passed and no migration was really required.






docker kubernetes docker-swarm application-management







share|improve this question




























    up vote
    0
    down vote

    favorite












    Docker Swarm and Kubernetes are two systems to manage applications on several nodes. If a node is draining or its load is very high they start some procedure to maintain the desired state described in the requirements.



    Of course, when they manage the application over the infrastructure, they have to take some choices in order to modify the state. How the decisions are taken in order to ensure that the decisions don't damage the system?



    I mean, not when the actions are triggered (system analysis) but how can we prove that the decision taken are the best decision to resolve the problem?
    There is some documentation on that? I don't find any referring to this topic.



    For example:
    I have a node which resources are almost free. Then, at a certain moment, their resources became insufficient, and remain insufficient just for a second, then return free. If the manager migrates applications from that node to another one because of that second of insufficient resources has trigged the migration functions, probably it will create more problem than solved ones since the insufficient resources problem are already passed and no migration was really required.






    docker kubernetes docker-swarm application-management







    share|improve this question


























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      Docker Swarm and Kubernetes are two systems to manage applications on several nodes. If a node is draining or its load is very high they start some procedure to maintain the desired state described in the requirements.



      Of course, when they manage the application over the infrastructure, they have to take some choices in order to modify the state. How the decisions are taken in order to ensure that the decisions don't damage the system?



      I mean, not when the actions are triggered (system analysis) but how can we prove that the decision taken are the best decision to resolve the problem?
      There is some documentation on that? I don't find any referring to this topic.



      For example:
      I have a node which resources are almost free. Then, at a certain moment, their resources became insufficient, and remain insufficient just for a second, then return free. If the manager migrates applications from that node to another one because of that second of insufficient resources has trigged the migration functions, probably it will create more problem than solved ones since the insufficient resources problem are already passed and no migration was really required.






      docker kubernetes docker-swarm application-management







      share|improve this question















      Docker Swarm and Kubernetes are two systems to manage applications on several nodes. If a node is draining or its load is very high they start some procedure to maintain the desired state described in the requirements.



      Of course, when they manage the application over the infrastructure, they have to take some choices in order to modify the state. How the decisions are taken in order to ensure that the decisions don't damage the system?



      I mean, not when the actions are triggered (system analysis) but how can we prove that the decision taken are the best decision to resolve the problem?
      There is some documentation on that? I don't find any referring to this topic.



      For example:
      I have a node which resources are almost free. Then, at a certain moment, their resources became insufficient, and remain insufficient just for a second, then return free. If the manager migrates applications from that node to another one because of that second of insufficient resources has trigged the migration functions, probably it will create more problem than solved ones since the insufficient resources problem are already passed and no migration was really required.






      docker kubernetes docker-swarm application-management




      docker kubernetes docker-swarm application-management






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 2 days ago

























      asked 2 days ago









      alessandro308

      1771211




      1771211
























          2 Answers
          2






          active

          oldest

          votes

















          up vote
          0
          down vote













          Kubernetes not validate their management choice it just spawn on pods on any node where you have resources. But if you want to manage how it works with resources you could use resources limits.



          Also if you have this behavior when during some migration your application use a lot of resource for a short period and you don't want to Kubernetes move this pods anywhere you could start use pod soft affinity you application will try to spawn only on nods which you want, and only if it has no resources or possibility it will spawn pod in another node.






          share|improve this answer




























            up vote
            0
            down vote













            Swarm will not move a container because resources change in real time. You can control how it's initially scheduled with resource reservations and limits, but if something else eats up node resources, it won't move a healthy app.






            share|improve this answer





















            • Ok, but the question is the same: how to validate that choice?
              – alessandro308
              20 hours ago











            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',
            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%2f53373143%2fhow-docker-swarm-and-kubernetes-validate-their-management-choices%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote













            Kubernetes not validate their management choice it just spawn on pods on any node where you have resources. But if you want to manage how it works with resources you could use resources limits.



            Also if you have this behavior when during some migration your application use a lot of resource for a short period and you don't want to Kubernetes move this pods anywhere you could start use pod soft affinity you application will try to spawn only on nods which you want, and only if it has no resources or possibility it will spawn pod in another node.






            share|improve this answer

























              up vote
              0
              down vote













              Kubernetes not validate their management choice it just spawn on pods on any node where you have resources. But if you want to manage how it works with resources you could use resources limits.



              Also if you have this behavior when during some migration your application use a lot of resource for a short period and you don't want to Kubernetes move this pods anywhere you could start use pod soft affinity you application will try to spawn only on nods which you want, and only if it has no resources or possibility it will spawn pod in another node.






              share|improve this answer























                up vote
                0
                down vote










                up vote
                0
                down vote









                Kubernetes not validate their management choice it just spawn on pods on any node where you have resources. But if you want to manage how it works with resources you could use resources limits.



                Also if you have this behavior when during some migration your application use a lot of resource for a short period and you don't want to Kubernetes move this pods anywhere you could start use pod soft affinity you application will try to spawn only on nods which you want, and only if it has no resources or possibility it will spawn pod in another node.






                share|improve this answer












                Kubernetes not validate their management choice it just spawn on pods on any node where you have resources. But if you want to manage how it works with resources you could use resources limits.



                Also if you have this behavior when during some migration your application use a lot of resource for a short period and you don't want to Kubernetes move this pods anywhere you could start use pod soft affinity you application will try to spawn only on nods which you want, and only if it has no resources or possibility it will spawn pod in another node.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered yesterday









                Nick Rak

                899211




                899211
























                    up vote
                    0
                    down vote













                    Swarm will not move a container because resources change in real time. You can control how it's initially scheduled with resource reservations and limits, but if something else eats up node resources, it won't move a healthy app.






                    share|improve this answer





















                    • Ok, but the question is the same: how to validate that choice?
                      – alessandro308
                      20 hours ago















                    up vote
                    0
                    down vote













                    Swarm will not move a container because resources change in real time. You can control how it's initially scheduled with resource reservations and limits, but if something else eats up node resources, it won't move a healthy app.






                    share|improve this answer





















                    • Ok, but the question is the same: how to validate that choice?
                      – alessandro308
                      20 hours ago













                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    Swarm will not move a container because resources change in real time. You can control how it's initially scheduled with resource reservations and limits, but if something else eats up node resources, it won't move a healthy app.






                    share|improve this answer












                    Swarm will not move a container because resources change in real time. You can control how it's initially scheduled with resource reservations and limits, but if something else eats up node resources, it won't move a healthy app.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 20 hours ago









                    Bret Fisher

                    3,03611221




                    3,03611221












                    • Ok, but the question is the same: how to validate that choice?
                      – alessandro308
                      20 hours ago


















                    • Ok, but the question is the same: how to validate that choice?
                      – alessandro308
                      20 hours ago
















                    Ok, but the question is the same: how to validate that choice?
                    – alessandro308
                    20 hours ago




                    Ok, but the question is the same: how to validate that choice?
                    – alessandro308
                    20 hours ago


















                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53373143%2fhow-docker-swarm-and-kubernetes-validate-their-management-choices%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







                    Popular posts from this blog

                    Can a sorcerer learn a 5th-level spell early by creating spell slots using the Font of Magic feature?

                    Image
                    28 6 $begingroup$ Per the Font of Magic feature, sorcerer can use Flexible Casting to create 5th-level spell slots at level 7, even though they are not typically available until level 9. You can transform unexpended sorcery points into one spell slot as a bonus action on your turn. The Creating Spell Slots table shows the cost of creating a spell slot of [5th level is 7] If such a sorcerer levels up while still having this 5th-level spell slot, can they choose a 5th-level spell as the spell they gain upon levelling up? The Spellcasting feature states: Additionally, when you gain a level in this class, you can choose one of the sorcerer spells you know and replace it with another spell from the sorcerer spell list, which also must be of a level for which you have spell slots.
                    Read more

                    Does disintegrating a polymorphed enemy still kill it after the 2018 errata?

                    Image
                    up vote 13 down vote favorite 1 After the 2018 errata, the disintegrate spell description now reads: A creature targeted by this spell must make a Dexterity saving throw. On a failed save, the target takes 10d6 + 40 force damage. The target is disintegrated if this damage leaves it with 0 hit points. If you were to polymorph an enemy into a rat and then disintegrate it, would the enemy be disintegrated or would it just return to its original form? I know that for Druids, it’s not an instant kill anymore, but is this the case for polymorph as well? dnd-5e spells polymorph errata share | improve this question edited 18 hours ago
                    Read more

                    A Topological Invariant for $pi_3(U(n))$

                    Image
                    3 3 $begingroup$ Recently, I saw a construction of topological invariant for $pi_3(U(n))$ with $ngeq 2$ : $$ N=frac{1}{24pi^2}int_{S^3} d^3x epsilon^{ijk} Tr[(U^{-1}partial_{x_i}U)(U^{-1}partial_{x_j}U)(U^{-1}partial_{x_k}U)] , $$ where $Uin U(n)$ depends on $boldsymbol{x}=(x_1,x_2,x_3)in S^3$ , $epsilon^{ijk}$ is the Levi-Civita symbol, $i,j,k=1,2,3$ , and the duplicated indexes are summed over. It is claimed that $N$ is an integer, but why? Update 02/02/2019 I think I got an argument for $n=2$ . In this case, $U=e^{i varphi} q$ with $qin SU(2)$ . Due to the trace and the Levi-Civita symbol in $N$ , $varphi$ does not contribute to $N$ . As $Tr[q^{dagger}partial_i q]=0$ and $(q^{dagger}partial_i q)^{dagger}=-q^{dagger}partial_i q$ , $q^{dagger}partial_i q$ in geneeral has the form $q^{dagger}partia
                    Read more