Kuryr ignores CNI_CONTAINERID when serving requests
Bug #1731485 reported by
Michal Dulko
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kuryr-kubernetes |
Fix Released
|
Critical
|
Michal Dulko |
Bug Description
Kuryr relies on pod name to identify VIFs attached to a pod, as that's easily accessible through k8s API. The problem with that is - kubelet and CNI rely on CNI_CONTAINERID. There's a common failure scenario when creating multiple pods simultaneously:
1. Kubelet sends ADD request with CNI_CONTAINERID=A.
2. ADD request fails.
3. Kubelet sends DEL request with CNI_CONTAINERID=A.
4. Kubelet sends ADD request with CNI_CONTAINERID=B.
5. ADD request succeeds.
6. DEL request #3 takes a long time, so kubelet sends another DEL with CNI_CONTAINERID=A.
7. Kuryr disconnects pod from the network.
Changed in kuryr-kubernetes: | |
assignee: | nobody → Michal Dulko (michal-dulko-f) |
status: | New → In Progress |
Changed in kuryr-kubernetes: | |
importance: | Undecided → High |
Changed in kuryr-kubernetes: | |
importance: | High → Critical |
Changed in kuryr-kubernetes: | |
status: | In Progress → Fix Released |
To post a comment you must log in.
In CNI daemon patch [1] this is solved by saving last CNI_CONTAINERID into memory and only reacting to DEL requests that have the same CNI_CONTAINERID. I don't know how to solve this for regular CNI plugin case.
[1] https:/ /review. openstack. org/#/c/ 515186