Okoz tényleges problémát is, sajnos. Nem tudom ismered-e a kiam-agent-et. Az úgy működik hogy az AWS magic IP címére - 169.254.169.254 - felvesz egy DNAT iptables rulet és az arra kimenő forgalmat magára irányítja. Így amikor egy pod az AWS SDK-t használva keresi az EC2 instance role-t a kiam-agent - és utána a kiam-server - kapja a kérést, megnézni milyen annotation van a podon, assume-olja azt a role-t és azt a session-t adja vissza.
Nálunk ez történik:
- Elindul egyszerre a kiam-agent és a calico-node pod.
- A calico-node felhúzza a CNI-t, de még 70 másodpercig nem elérhető a pod network.
- A kiam-agent readiness checkje zöld, mivel csak shallow check-et végez. Nem ellenőrzi hogy tud-e az APIserver-hez csatlakozni, csak azt hogy listenel-e valami lokális porton. Ezt egy későbbi verzióban javították.
- A nidhogg törli a kiam-agent taintjét a node-ról.
- Nincs több taint a node-on, a scheduler beütemezhet új production podokat a node-ra.
- A kiam-agent eltimeoutol az APIserver-hez csatlakozás során - keresi a kiam-server ClusterIP Service-t. A k8s-proxy az APIserver - 10.2.0.1 - IP címét egy valós pod networkös IP címre oldja fel - 10.1.x.y. Mivel a pod network route-ja még nincsenek meg ez elmegy az VPC routere felé, aka default gateway. Mivel az AWS routere csak eldobja a forgalmat - mintha blackhole lenne - ezért nincs ICMP üzenet, leketyeg a teljes timeout.
- A nidhogg visszarakja a taintet, de ha a scheduler a korábban már ütemezett podokat nem költözteti el.
- A pod elindul és kívánt AWS role helyett a Kubernetes worker node role-ját fogja megkapni. Ezzel nagy eséllyel nem fér hozzá a számára szükséges AWS resource-okhoz. Ha a fejlesztők ügyesek voltak, akkor a pod terminál, ha nem akkor folyamatosan újrapróbálkozik. Ha ez egy ősrégi legacy kód, akkor azt már senki nem fogja javítani.
Szóval meg lehet ezt workaroundolni, de költözés előtt már nem érdemes effortot ölni bele.
Csak azt akartam kiemelni a legelső hozzászólásommal hogy az hogy a Kubernetes manage-eli azt a szolgáltatást ami magát a Kubernetes network-öt építi fel okozhat nem várt problémákat is. Amikor mi elkezdtük a calico-t használni - még mesh és nem RR módban - nem volt sem kiam-agent, sem nidhogg. Ezeket utólag vezettük be és ezek "rontották el" a korábban jól működő calicot. Külön-külön minden teljesen rendben van, így együtt azonban egy szép race conditiont adnak ki.