delete pod-network-delay rule will be failure when the pod restart

[bmbbms]

Issue Description

bug report

Describe what happened (or what feature you want)

when i set a network delay rule for a pod, it make pod livness probe failed,and the pod will be restarted. at this time, if i want to delete the network delay rules ,it will be failure ,because the containerId will be changed when the pod restart. actually the network delay rule continue using the origin containerId to delete the pod network delay.

Describe what you expected to happen

so the containerId is not good for the specified rules. we should theck the Identifier's containerId whether changed when delete failure

How to reproduce it (as minimally and precisely as possible)

1. first deply a network delay for a pod

       Status:
         Exp Statuses:
           Action:  delay
           Res Statuses:
             Id:          b42b0ee218262ce9
             Identifier:  test-testing-dc-k2030/172.20.35.51/reliable-msg-route-5fdc8cc757-hwvdt/reliable-msg-route/18f0b9d032ce
             Kind:        pod
             State:       Success
             Success:     true
           Scope:         pod
           State:         Success
           Success:       true
           Target:        network
         Phase:           Running
       Events:            <none>

2. make sure the delay can result in the pod live probe failed and restart

   test-testing-dc-k2030         reliable-msg-route-5fdc8cc757-hwvdt               1/1     Running            4          3d      192.168.137.81    172.20.35.51   <none>           <none>

3. delete the rule

Status: Exp Statuses: Action: delay Error: see resStatus for the error details Res Statuses: Error: Error response from daemon: No such container: 18f0b9d032ce Id: b42b0ee218262ce9 Identifier: test-testing-dc-k2030/172.20.35.51/reliable-msg-route-5fdc8cc757-hwvdt/reliable-msg-route/18f0b9d032ce Kind: pod State: Error Success: false Scope: pod State: Success Success: false Target: network Phase: Destroying

4. if i delete the rule force,actually the delay rules still in the pod

### Tell us your environment
k8s v1.16.15
chaosblade-operator-v0.9.0

### Anything else we need to know?

[xcaspar]

You can set --daemonset-enable=false flag to close sidecar model when deploying chaosblade-operator to solve the problem.

[bmbbms]

i see the default value of this parm is false.

[xcaspar]

You can delete the pod to recover it. I will solve this problem later.

[bmbbms]

actually it will work well when i apply the rule again using --force ,and i will success delete the rule before the pod next restarting . but i think it not a perfect way for doing that,so i report the bug.

[yzhang559]

@xcaspar I am using chaosblade-operator-v1.3.0 and k8s v1.21.4, still faced with this issue. Would there be any fix on next release or is there any work around to bypass this issue. Thanks.