kuryr-k8s may not work properly in a multi-cni cluster

Bug #1681338 reported by Kirill Zaitsev on 2017-04-10
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

There are currently no checks, that would skip pods not managed by kuryr-CNI. Kuryr-k8s expects that all new pods would be properly annotated by kuryr-cni. This might lead to kuryr-k8s crashes and is mentioned in a comment here: https://github.com/openstack/kuryr-kubernetes/blob/f7e64fbe6106012a78ac65dbc2fb1018fdb1b85d/kuryr_kubernetes/controller/handlers/vif.py#L50

This also applies to Services/lbaas support: see discussion here https://review.openstack.org/#/c/376045/20/kuryr_kubernetes/controller/handlers/lbaas.py

Changed in kuryr-kubernetes:
milestone: none → pike-2
importance: Undecided → High
status: New → Triaged
longfei.zhang (longfei.zhang) wrote :

Yes, we also have this requirement.
In a kubernetes ready environment, if we deploy kuryr later when needed, then some existing pods/LB would cause a lot
of error , kuryr controller get incorrect pod/LB info from those already existing pods/LB, then some times we can find kuryr-k8s crashed at last.

@longfei.zhang @kzaitsev

Do you have some idea about what would be acceptabe in this case to determine if we should serve a pod or a service?

I had a couple of ideas:

a) An annotation to inhibit kuryr
b) With multi-network support allow kuryr to be configured as 'on by default' and 'off by default'. In the latter case, it would only act on networks with a kuryr annotation.
c) Implemented in some driver. The driver would raise an exception like "NotKuryrManaged"

Changed in kuryr-kubernetes:
milestone: pike-2 → pike-3
Kirill Zaitsev (kzaitsev) wrote :

I like the 2 option more.

However at this point I'd say that it is safe to downgrade importance to med or low. Is there user-demand for this kind of setup/functionality?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers