( arpad | 2020. 12. 17., cs – 15:25 )

A jelenlegi stack nem tökéletes - és még finom voltam. A probléma egyébként az hogy a calico-node pod ~70 másodpercet vár - legalábbis a naplója szerint - mire felhúzná a pod networkinget. Ez egy ismert hiba a calico-ban, de most nem fogom tudni neked előkeresni a GitHub issue-t. Szabin vagyok, januárig elő sem akarom venni a céges notebookot.

Míg a calico vár a kiam-agent pod is megpróbál elindulni, de a healthcheck pár másodperc után lelövi - igen, ez sem szerencsés, ezt is workaroundolni kellene. A gond a szinte azonnal, mert van egy rövid időszak amikor a kiam-agent úgy néz ki hogy fut, a nidhogg leveszi a taintet és a scheduler elindíthat production podot is a node-on. Ha ez összejön akkor a production pod az EC2 instance role-t fogja látni és nem azt amit "felannotált" magának. Hogy ezt hogy kezeli az meg attól a csapattól függ aki implementálta.

Nagyon sok mindennek történelmi okai vannak, tipikus "organikusan fejlődőtt" stack olyan mélyen hard kódolt indirekt függőségekkel a környezet felé, hogy hozzányúlni már sokkal rizikósabb mint magát a workloadot migrálni egy új, remélhetőleg rendesen meg is tervezett megoldásra. Szóval ettől akarunk szabadulni és tiszta lappal kezdeni.

A calico-t azért akarjuk kidobni mert igazából felesleges jelenleg. Mivel a cluster amúgy is egy dedikált VPC-ben fog futni a pod-ok kaphatnak abból közvetlenül IP címeket. Erre az AWS-nek van saját CNI-je és akkor nem kell tunnelezni, nem kell Layer 3-on route-olni a forgalmat, van Layer 2-es direkt kapcsolat.