Mixing
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 asked 2 days ago
alessandro308
1771211
add a comment |
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 asked 2 days ago
alessandro308
1771211
add a comment |
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 asked 2 days ago
alessandro308
1771211
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 asked 2 days ago
alessandro308
1771211
asked 2 days ago
alessandro308
1771211
edited 2 days ago
asked 2 days ago
alessandro308
1771211
asked 2 days ago
alessandro308
1771211
asked 2 days ago
alessandro308
1771211
1771211
add a comment |
add a comment |
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.
answered yesterday
Nick Rak
899211
add a comment |
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.
answered 20 hours ago
Bret Fisher
3,03611221
Ok, but the question is the same: how to validate that choice?
– alessandro308
20 hours ago
add a comment |
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.
answered yesterday
Nick Rak
899211
add a comment |
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.
answered yesterday
Nick Rak
899211
add a comment |
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.
answered yesterday
Nick Rak
899211
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.
answered yesterday
Nick Rak
899211
answered yesterday
Nick Rak
899211
answered yesterday
Nick Rak
899211
answered yesterday
Nick Rak
899211
899211
add a comment |
add a comment |
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.
answered 20 hours ago
Bret Fisher
3,03611221
Ok, but the question is the same: how to validate that choice?
– alessandro308
20 hours ago
add a comment |
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.
answered 20 hours ago
Bret Fisher
3,03611221
Ok, but the question is the same: how to validate that choice?
– alessandro308
20 hours ago
add a comment |
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.
answered 20 hours ago
Bret Fisher
3,03611221
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.
answered 20 hours ago
Bret Fisher
3,03611221
answered 20 hours ago
Bret Fisher
3,03611221
answered 20 hours ago
Bret Fisher
3,03611221
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
add a comment |
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
add a comment |
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%2f53373143%2fhow-docker-swarm-and-kubernetes-validate-their-management-choices%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
