You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We generate the cluster state history and final cluster state and build our general-purpose oracles (event-oracle and resource-oracle) on top of them. The general-purpose oracles simply compare the history (creation/deletion events) and the final state across learning/testing runs. They do not require any knowledge specific to a controller and can be applied to every controller.
Ideally, we want to compare every field (e.g., replica, status) of every resource (e.g., pod, statefulset). However, we find that in k8s cluster resources tend to have random names. We identified two types of random names so far:
the random name derived from generateName. This usually happens to pods belonging to a deployment. A deployment mydeployment can own a pod with a random name mydeployment-12ab5.
the random name w/o generateName. For example sometimes secret objects have fully random names.
These random names are causing trouble in comparing the state/history: for example, say we observe a secret named mysecret-12ab5 in learning run (but not in testing run) and a secret named mysecret-09zy8 in testing run (but not in learning run), we have no way to tell whether they two logically represent the same resource and should be compared. Simply comparing the two resources that are not logically the same one can lead to confusing false alarms.
Currently, when encountering the above situation, we have to mask the value of such resources and only leverage very limited information (say the number of secrets) in the oracle. We welcome any help that can eliminate the randomness in the resource name, which can help us build better oracles.
The text was updated successfully, but these errors were encountered:
marshtompsxd
changed the title
Randomness in resource names that prevents more fine-grained oracle implementation
Randomness in resource names prevents more fine-grained oracle implementation
Oct 14, 2021
marshtompsxd
changed the title
Randomness in resource names prevents more fine-grained oracle implementation
Randomness in resource names obstructs more fine-grained oracle implementation
Oct 14, 2021
We generate the cluster state history and final cluster state and build our general-purpose oracles (event-oracle and resource-oracle) on top of them. The general-purpose oracles simply compare the history (creation/deletion events) and the final state across learning/testing runs. They do not require any knowledge specific to a controller and can be applied to every controller.
Ideally, we want to compare every field (e.g.,
replica
,status
) of every resource (e.g.,pod
,statefulset
). However, we find that in k8s cluster resources tend to have random names. We identified two types of random names so far:generateName
. This usually happens to pods belonging to a deployment. A deploymentmydeployment
can own a pod with a random namemydeployment-12ab5
.generateName
. For example sometimessecret
objects have fully random names.These random names are causing trouble in comparing the state/history: for example, say we observe a secret named
mysecret-12ab5
in learning run (but not in testing run) and a secret namedmysecret-09zy8
in testing run (but not in learning run), we have no way to tell whether they two logically represent the same resource and should be compared. Simply comparing the two resources that are not logically the same one can lead to confusing false alarms.Currently, when encountering the above situation, we have to mask the value of such resources and only leverage very limited information (say the number of secrets) in the oracle. We welcome any help that can eliminate the randomness in the resource name, which can help us build better oracles.
The text was updated successfully, but these errors were encountered: