Closed laphets closed 3 years ago
Nice catch!
The basic idea is that k8s will add some special prefix to certain resources as the key stored in etcd. For endpoints, the key is then transformed into services/endpoints, for service, the key is services/specs. As for our matching, we also need to consider for those special prefix.
Yes, the different naming (and even different data structures) for the same resource object at different components is tricky. We might need some rules to associate such events.
close; if my understanding is correct, we don't find new bugs but it helps match the events in the learning stage to make sure we don't miss later.
As mentioned in previous meeting, through batch analysis on mongodb operator, there are some cases that have matched for crucial event, but not detect side effect event on API server side (however, we observed side effect issued by the operator). And all of those failed patterns have the crucial event of
service
, e.g.After dumping all the event keys from here, I observed that keys related to
service
is like/services/specs/default/mongodb-cluster-cfg
or/services/endpoints/default/mongodb-cluster-cfg
, and the event resource is parsed asspec
/endpoints
instead ofservice
according to logic here.After looking into some source code of k8s, I figure the reason behind this. The basic idea is that k8s will add some special prefix to certain resources as the key stored in etcd. For
endpoints
, the key is then transformed intoservices/endpoints
, forservice
, the key isservices/specs
. As for our matching, we also need to consider for those special prefix.The current fix is to manually map the
services/endpoints
toendpoints
, andservices/specs
toservices
. After the fix,service
related side effect event can be successfully detected and sieve can then detect bug related toservice
ADD / DELETE.