Vrem să știm ce algoritm folosește rețeaua Docker pentru a direcționa cererile către containere. Iata de ce:

Implementăm aplicațiile noastre în grupuri de docker auto-găzduite. Folosim rețeaua de rutare docker pentru a direcționa traficul către nodurile individuale, astfel:

• internet ->
• firewall ->
• director de încărcare (nginx) ->
• rutare „cel mai puțină conexiune” nginx către trei manageri de roi ->
• docker mesh ->
• Oricare dintre cele șase containere de aplicații care rulează pe trei noduri docker diferite, non-manager

Dezvoltatorii noștri bănuiesc că rețeaua docker direcționează traficul round robin, ceea ce ar putea duce la supraîncărcarea unor containere de aplicații cu solicitări lente, în timp ce alte containere sunt subutilizate. Dacă dezvoltatorii au dreptate, nu ar trebui să folosim rețeaua docker, ci ar trebui să folosim directorul de încărcare pentru a direcționa traficul către containerele individuale folosind un algoritm mai inteligent decât round robin.

Pe de altă parte, dacă rețeaua docker ține evidența câte solicitări sunt în zbor către fiecare container și livrează trafic către containerul cu cele mai puține solicitări, atunci nu trebuie să facem munca de ocolire a rețelei docker.

Intrebarea

Ce algoritm folosește rețeaua docker pentru a direcționa traficul către containerele disponibile? Este simplu round robin?

Configurația noastră nginx

Nginx-ul nostru primește trafic de pe internet și îl trimite prin proxy către rețeaua docker de pe oricare dintre cele trei noduri de manager docker:

în amonte document_service {
  minimum_conn;
  server dockermgr1.nosuchdomain:8402;
  server dockermgr2.nosuchdomain:8402;
  server dockermgr3.nosuchdomain:8402;
}

Server {
...
        proxy_pass http://document_service;

Configurația noastră docker-compose

Fișierul docker-compose configurează serviciul să aibă șase replici pe cele trei noduri docker runner:

versiune: "3.4"

Servicii:
  Serviciu documente:
    imagine: ${IMAGE_LOCATION}documents_service/documentsservice:prod-${COMPOSE_BUILD_TAG:-latest}
    container_name: documentservice
    porturi:
      - „8402:80”
    ...
    implementeaza:
      replici: 6
      plasare:
        constrângeri: [node.role != manager]
      resurse:
        limite:
          memorie: 1024 MB
      update_config:
        paralelism: 1
        ordine: începe-primul
        failure_action: continua

Versiuni

• docker-ce 5:19.03.12~3-0~debian-buster
• nginx-full 1.14.2-2+deb10u4
• docker-compose: 1.27.4

Dirijarea prin rețea este cel mai probabil numai round robin

Am făcut o scufundare în sursa docker. Am găsit referiri la diferite metode de rutare, dar singura care pare a fi folosită este round robin. Am găsit, de asemenea, o întrebare pe forumul docker care pare să confirme că rutarea prin rețea este doar round-robin.

Examinând sursa

În vendor/github.com/moby/ipvs/constants.go este aceasta lista interesanta de strategii de rutare:

const (                                                                                                                                                                                        
        // RoundRobin distribuie joburile în mod egal între cele disponibile                                                                                                                           
        // servere reale.                                                                                                                                                                       
        RoundRobin = "rr"                                                                                                                                                                      
                                                                                                                                                                                               
        // LeastConnection atribuie mai multe locuri de muncă serverelor reale cu                                                                                                                              
        // mai puține locuri de muncă active.                                                                                                                                                                  
        LeastConnection = "lc"                                                                                                                                                                 
                                                                                                                                                                                               
        // DestinationHashing atribuie locuri de muncă serverelor prin căutare                                                                                                                          
        // susține un tabel hash atribuit static în funcție de IP-ul de destinație                                                                                                                         
        // adrese.                                                                                                                                                                          
        DestinationHashing = „dh”                                                                                                                                                              
                                                                                                                                                                                               
        // SourceHashing atribuie locuri de muncă serverelor prin căutarea în sus                                                                                                                            
        // un tabel hash atribuit static după IP-ul sursă                                                                                                                                 
        // adrese.                                                                                                                                                                          
        SourceHashing = „sh”                                                                                                                                                                   
                                                                                                                                                                                               
        // WeightedRoundRobin atribuie locuri de muncă serverelor reale proporțional                                                                                                                      
        // la greutatea reală a serverelor. Servere cu greutăți mai mari                                                                                                                          
        // primiți mai întâi noi locuri de muncă și obțineți mai multe locuri de muncă decât servere                                                                                                                               
        // cu greutăți mai mici. Serverele cu greutăți egale primesc                                                                                                                                  
        // o distribuție egală a noilor locuri de muncă                                                                                                                                                   
        WeightedRoundRobin = „wrr”                                                                                                                                                             
                                                                                                                                                                                               
        // WeightedLeastConnection atribuie mai multe joburi serverelor                                                                                                                                
        // cu mai puține locuri de muncă și relativ la greutatea reală a serverelor                                                                                                                            
        WeightedLeastConnection = „wlc”                                                                                                                                                        
)  

Cu toate acestea, singura dintre aceste constante care este folosită este RoundRobin:

wayne@treebeard:~/temp/docker-src/moby$ ack 'ipvs\.(RoundRobin|LeastConnection|DestinationHashing|SourceHashing|WeightedRoundRobin|WeightedLeastConnection)'
libnetwork/service_linux.go
117: SchedName: ipvs.RoundRobin,
225: s.SchedName = ipvs.RoundRobin

Deși aceasta a fost o privire foarte superficială asupra sursei, nu am găsit niciun mijloc evident de a configura modul de rutare să fie altceva decât RoundRobin.

O întrebare legată de pe forumurile docker

O întrebare pe forumul docker pare să confirme că singura metodă de rutare disponibilă pentru mesh este round robin:

https://forums.docker.com/t/configure-swarm-mode-routing-mesh-load-balancing-method/75413

Am citit că echilibrul de încărcare a rețelei de rutare în modul roi folosește round-robin (https://success.docker.com/article/ucp-service-discovery#externalloadbalancing(swarmmoderoutingmesh) 15).

Există posibilitatea de a configura metoda de echilibrare a sarcinii (de ex.(ponderat) cea mai mică conexiune, hashing sursă/destinație...) a rețelei de rutare a modului roi?

Raspunsul a fost:

Mesh-ul de rutare în modul roi, alias ingress, acționează pe layer4 și nu știe despre acele detalii de configurare pe care le solicitați. Documentația poate fi găsită aici: https://docs.docker.com/engine/swarm/ingress/ 45. Linkul pe care l-ați lipit are ca scop „de ce să folosiți proxy-ul de interblocare ca avantaje”.

Dacă aveți o licență de întreprindere: aveți dreptul să utilizați proxy-ul de interblocare, care face parte din UCP. Este un proxy invers/echilibrator de încărcare layer7. În vremurile când încercam versiunile timpurii de interlock, avea unele limitări. Din ceea ce am citit în jurnalul de modificări, versiunile actuale par să fie aproape de ceea ce este capabil să facă traefik.

Dacă rulați pe Docker-CE, poate doriți să aruncați o privire la traefik.