Should add a parent crd to obi : obig

[Abirdcfly]

Current Limitations:

1. In obi, it is not enough to use index and label to point to the same pod or node. When a deploy or node is updated, the same index may point to a different pod or node.
2. The lack of a resource or field to meet the need to monitor all nodes or all pods under a deploy is a requirement often used in schedulers

OBIG example:

apiVersion: arbiter.k8s.com.cn/v1alpha1
kind: ObservabilityIndicantGroup
metadata:
  name: metric-server-node-cpu
spec:
  obiHistoryLimit: 10 # How many additional instances of expired obi to keep, 0 means coincide with the actual resource updates, no expired obi to keep
  # Same as obi below, with only 2 minor differences:
  # 1. no `spec.targetRef.index`
  # 2. `spec.targetRef.kind` only support `Node` and `Deploy` now.
  metric:
    historyLimit: 1
    metricIntervalSeconds: 15
    metrics:
      cpu:
        aggregations:
        - time
        description: ""
        query: ""
        unit: 'm'
    timeRangeSeconds: 3600
  source: metric-server
  targetRef:
    group: ""
    kind: Node
    labels:
      "data-test": "data-test"
    name: ""
    namespace: ""
    version: v1

OBIG running logic:

The logic for running obig is as follows:

1. When an obig is created to monitor nodes, the observer queries what all the current nodes are, creates an obi for each node (obi spec.targetRef.name will be node name), adds a new obi to monitor the new node when there is a new node, and stops the obi update for the old node when there is a deletion and deletes it after triggering the history length limit spec.obiHistoryLimit.
2. monitor the obig of deploy in the same way. create obis for each pod (obi spec.targetRef.name will be pod name).

How arbiter-scheduler to use OBIG:

This can be used for the actual resource scheduling of the scheduler:

1. When the arbiter-scheduler is created. The arbiter-scheduler will automatically create one obig to monitor the actual resource usage of the node's cpu and memory.
2. The scheduler will only be responsible for creating this obig, the obi creation and update will be done by the observer, and if this obig is already created, the obig already created by user will be used.
3. The scheduler will only use the obi created by this obig. node.metric.cpu and node.metric.mem (by looking at the obig's ownerReferences) to update the metric that JS will use in the scheduler's Score CRD.