Load Balancing
wpisy (9)
Model OSI w klastrze i w chmurze: kto widzi co, kiedy otwierasz stronę
L3, L4 i L7 to skrót od pytania, jak głęboko dany element infrastruktury zagląda w ruch. Jeden request od kliknięcia "Zapłać" do poda payments, warstwa po…
- Kubernetes od środka: podstawy architektury klastra4/7
Networking w Kubernetes
CNI daje Podom adresy i łączność między sobą, a kube-proxy albo datapath na eBPF sprawia, że ruch na wirtualny adres Service trafia do właściwego endpointu…
Wprowadzenie do service mesh: po co Istio i Linkerd
Service mesh powstał dlatego, że w systemie mikroserwisów problemy z ruchem, tożsamością i obserwowalnością zaczęły powtarzać się w każdej usłudze.
- Realtime w przeglądarce: od pollingu do WebTransport5/7
WebSockets: trwały kanał komunikacji w obu kierunkach
Po handshake nie ma już requestów i odpowiedzi, tylko frames. Trwałe połączenie jest stanem, który dotyka load balancera, deployu i fan-outu między instancjami.
- Gateway API bez magii4/4
Migracja z ingress-nginx do Gateway API
Migracja z ingress-nginx nie jest mechaniczną translacją YAML-a. Najpierw trzeba oddzielić kontrakt aplikacji od zachowań konkretnego kontrolera.
- Gateway API bez magii3/4
GatewayClass: kontrakt z implementacją
GatewayClass nie jest nazwą środowiska. To punkt, w którym Kubernetes Gateway API spotyka się z konkretnym kontrolerem.
- Gateway API bez magii2/4
Gateway to nie zawsze to samo gateway
Słowo gateway miesza produkt, rolę sieciową i Kubernetes API. Bez tego rozdziału łatwo porównywać rzeczy z różnych warstw.
- Gateway API bez magii1/4
Od Service do Gateway API: skąd wziął się problem
Ingress nie przegrał dlatego, że był zły. Przegrał, bo jego mała specyfikacja nie miała języka na produkcyjne zachowania HTTP.
- seria · 4 części
Gateway API bez magii
Krótkie wejście do serii o tym, skąd wziął się Gateway API, czym różni się od Ingress i jak podejść do migracji z ingress-nginx.