Konrad Kowalski (rootsher)Principal Platform & Reliability Architect010101000000111101101010111100101111111000001100

Networking

wpisy (23)

  1. Realtime w przeglądarce: od pollingu do WebTransport6/7

    WebTransport: streams i datagramy dla realtime nad HTTP/3

    HTTP/3 i QUIC dają jednej sesji wiele niezależnych streamów oraz datagramy. Nie każde dane muszą dotrzeć niezawodnie i w kolejności.

  2. 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.

  3. 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.

  4. 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.

  5. Realtime w przeglądarce: od pollingu do WebTransport4/7

    Server-Sent Events: protokół zdarzeń nad HTTP streamingiem

    Standardowy format zdarzeń i reconnect nad strumieniem HTTP. Last-Event-ID daje wznowienie, ale trwałości eventów w systemie już nie załatwia.

  6. 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.

  7. 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.

  8. Realtime w przeglądarce: od pollingu do WebTransport3/7

    HTTP Streaming: jedna odpowiedź, wiele fragmentów danych

    Odpowiedź może powstawać w czasie. Chunk transportowy nie jest wiadomością, więc framing i backpressure stają się sprawą aplikacji.

  9. 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.

  10. 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.