Now, in the context of https://github.com/Mirantis/k8s-netchecker-server/issues/97, TPR will be used as a persistent storage for netchecker-server data. So, that netchecker-server make a TPR API request each time the new report is received from a netchecker-agent. So, it can make a considerably high load to the kubernetes API (and possibly etcd) on a scale.
In order to scale (https://github.com/Mirantis/k8s-netchecker-server/issues/35) well, let's consider using batch updates of TPRs. It can be made as agent data (and metrics) updates buffering and then flushing the accumulated data into TPRs. It's required first to ensure that kubernetes API supports updates on a collection.
Now, in the context of https://github.com/Mirantis/k8s-netchecker-server/issues/97, TPR will be used as a persistent storage for netchecker-server data. So, that netchecker-server make a TPR API request each time the new report is received from a netchecker-agent. So, it can make a considerably high load to the kubernetes API (and possibly etcd) on a scale.
In order to scale (https://github.com/Mirantis/k8s-netchecker-server/issues/35) well, let's consider using batch updates of TPRs. It can be made as agent data (and metrics) updates buffering and then flushing the accumulated data into TPRs. It's required first to ensure that kubernetes API supports updates on a collection.