Acest lucru nu este specific Kubernetes, acesta este un comportament normal al LACP. Nu oferă o creștere reală a debitului, mai degrabă acțiunea sa ar fi descrisă mai bine ca „distribuție deterministă a conexiuni" (nu pachete individuale) și o toleranță la erori.
Extrage din pachete câteva câmpuri de antet (determinate de mod) și le hash. De exemplu, modul hash „layer3+4” preia informațiile OSI de nivel 3 și 4, de ex. IP și portul. Hash-ul determină direct ce picior LACP să iasă din acest pachet. Indiferent de modul de hashing pe care îl alegeți, toate pachetele care aparțin aceleiași conexiuni vor fi hashing în același segment, deci orice conexiune nu ar putea depăși un singur nivel de debit.
Când apare o altă conexiune, dacă aveți noroc, ar putea folosi un alt picior LACP. În acest caz, două conexiuni vor fi distribuite între picioare și veți avea un debit total de două ori între gazde. Acest lucru nu este garantat: s-ar putea întâmpla ca ambii să fie direcționați prin același picior. Dar, atunci când aveți multe conexiuni (cum este de obicei atunci când luăm în considerare clusterele convergente), în medie vor fi utilizate ambele părți.
Pot compara asta cu Kubernetes, dacă doriți.Dacă adăugați noduri (și scalați implementarea în consecință), puteți crește numărul de clienți care ar putea fi deserviți de cluster. Dar nu puteți îmbunătăți latența de răspuns (timpul până la serviciu) unei anumite solicitări prin această scalare (dacă clusterul nu a fost supraîncărcat).
