This repository has been archived by the owner on May 3, 2022. It is now read-only.
Validate Service's .spec.selector when shifting traffic #257
Labels
enhancement
New feature or request
Comments
juliogreff
added a commit
that referenced
this issue
Jan 14, 2020
* It is more useful when we actually report the number we mean, instead of the exact opposite: we were reporting number of pods ready and told the users that was the number of pods not ready. Now we report it correctly. * It's weird to report 0 pods not ready, but still not get any traffic. We add some more clarity on that by reporting that there are pods that haven't made it into the endpoints yet. This can be k8s taking its time to do its thing, or the service selector might be incorrect. We should be able to catch an incorrect selector in the future, see #257 [1]. * To remain consistent with the errors we report in the Release, we now suggest the specific command to run to get more information about the CapacityTarget. [1] #257
juliogreff
added a commit
that referenced
this issue
Jan 15, 2020
* It is more useful when we actually report the number we mean, instead of the exact opposite: we were reporting number of pods ready and told the users that was the number of pods not ready. Now we report it correctly. * It's weird to report 0 pods not ready, but still not get any traffic. We add some more clarity on that by reporting that there are pods that haven't made it into the endpoints yet. This can be k8s taking its time to do its thing, or the service selector might be incorrect. We should be able to catch an incorrect selector in the future, see #257 [1]. * To remain consistent with the errors we report in the Release, we now suggest the specific command to run to get more information about the CapacityTarget. [1] #257
hihilla
pushed a commit
that referenced
this issue
Jan 20, 2020
* It is more useful when we actually report the number we mean, instead of the exact opposite: we were reporting number of pods ready and told the users that was the number of pods not ready. Now we report it correctly. * It's weird to report 0 pods not ready, but still not get any traffic. We add some more clarity on that by reporting that there are pods that haven't made it into the endpoints yet. This can be k8s taking its time to do its thing, or the service selector might be incorrect. We should be able to catch an incorrect selector in the future, see #257 [1]. * To remain consistent with the errors we report in the Release, we now suggest the specific command to run to get more information about the CapacityTarget. [1] #257
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Shipper now uses Endpoints to check for traffic progression (#238), which is an improvement over just checking that pods got their labels. If pods don't make it into the Endpoints object, shipper will no longer declare the TrafficTarget as Ready, but we're still lousy at relaying to the user what could possibly be wrong if the pods just don't make it.
There are two obvious reasons why that could happen. The first one, where we can't do much about, is that kubernetes is still busy taking the label shifting into account, but things will eventually converge.
The other reason, where things won't eventually converge, is when the app's Service object has a selector that will never match any pods. If that's the case, shipper will just say "0 out of X pods are not ready", which makes no sense (my traffic target should be ready if nothing is not ready!). To prevent that, the traffic controller should validate that the service has a selector that will match pods, and report the appropriate error through a condition in the TrafficTarget, before doing any actual traffic shifting.
The text was updated successfully, but these errors were encountered: