AWS EKS - EIA atașat la nod nu este accesibil de Pod

Folosesc un standard AWS EKS cluster, toate bazate pe cloud (K8S 1.21) cu mai multe grupuri de noduri, dintre care unul folosește un șablon de lansare care definește un accelerator elastic de inferență atașat instanțelor (eia2.mediu) a servi un fel de Tensorflow model.

M-am chinuit foarte mult pentru ca modelul nostru de învățare profundă să funcționeze deloc în timpul implementării, și anume am un Pod într-o implementare cu un cont de serviciu și o politică EKS IRSA atașată, care se bazează pe Container AWS Deep Learning pentru servirea modelului de inferență bazat pe Tensorflow 1.15.0.

Imaginea folosită este 763104351884.dkr.ecr.eu-west-1.amazonaws.com/tensorflow-inference-eia:1.15.0-cpu și atunci când modelul este implementat în cluster, cu o afinitate de nod cu cel adecvat Activat EIA nod, pur și simplu nu funcționează când este apelat folosind /invocari punct final:

Utilizarea bibliotecii client Amazon Elastic Inference Versiunea: 1.6.3
Numărul de acceleratoare elastice de inferență disponibile: 1
Elastic Inference Accelerator ID: eia-<id>
Tip accelerator de inferență elastică: eia2.medium
Ordinal accelerator de inferență elastică: 0

2022-05-11 13:47:17.799145: F external/org_tensorflow/tensorflow/contrib/ei/session/eia_session.cc:1221] Stare non-OK: SwapExStateWithEI (tmp_inputs, tmp_outputs), starea tmp_freeze: tmp_freeze) obțineți lista albă a operatorului inițial de pe server.
AVERTISMENT:__main__:ieșire neașteptată a tensorflow-ului (stare: 134). repornind.

Doar ca referință, atunci când utilizați Numai CPU imagine disponibilă la 763104351884.dkr.ecr.eu-west-1.amazonaws.com/tensorflow-inference:1.15.0-cpu, modelul servește perfect în orice mediu (și local).

Fiecare nod EKS și Podul însuși (prin IRSA) au următoarea politică atașată:

{
    „Versiune”: „2012-10-17”,
    "Afirmație": [
        {
            „Efect”: „Permite”,
            "Acțiune": [
                „elastic-inference:Connect”,
                "iam:List*",
                "iam:Get*",
                "ec2:Descrie*",
                „ec2:Obțineți*”,
                „ec2:ModifyInstanceAttribute”
            ],
            „Resurse”: „*”
        }
    ]
}

conform documentației de la AWS însuși, am creat și un punct final VPC pentru inferență elastică așa cum este descris de AWS și l-am legat de subrețelele private utilizate de nodurile EKS împreună cu un grup de securitate configurat corespunzător, care permite SSH, HTTPS și 8500/8501 Porturi TCP de la orice nod de lucru din CIDR VPC.

Folosind atât Analizor de accesibilitate AWS si Simulatorul de politici IAM nimic nu pare greșit, iar rețelele și permisiunile par în regulă, în timp ce, de asemenea, EISetupValidator.py scriptul furnizat de AWS spune același lucru.

Vreo indiciu despre ce se întâmplă de fapt aici? Îmi lipsesc un fel de permisiuni sau de configurare a rețelei?