Konrad Kowalski (rootsher)Principal Platform & Reliability Architect110100000111110101111101001110010100011111101011

kategorie

Principal Platform & Reliability Architect

Po kolei - z czego składa się ta rola i co w każdym z obszarów do niej należy.

01
Automatyzacja i kultura DevOpsInfrastructure as Code
Promowanie podejścia Infrastructure as Code (IaC, np. Terraform) zamiast klikania po konsoli, pakowanie usług w Helm charty i wdrażanie ich na Kubernetes w modelu GitOps - ArgoCD pilnuje, żeby stan klastra zgadzał się z repozytorium, więc wdrożenie jest scaleniem gałęzi. Automatyzacja procesów CI/CD zdejmuje z zespołu powtarzalną pracę manualną (tzw. toil).
02
Standardy SRE i observabilitySLI / SLO
Wdrażanie observability, czyli zdolności odpowiedzenia na pytanie „co się właśnie stało” bez logowania się na serwer: Prometheus i Grafana pod metryki oraz alerty, New Relic jako APM - logi, ślady żądań, czasy odpowiedzi i wąskie gardła w jednym miejscu, OpenTelemetry jako niezależny od dostawcy sposób instrumentacji, Sentry pod błędy aplikacji. Określanie na tym wskaźników stabilności: SLI (Service Level Indicators) oraz SLO (Service Level Objectives).
03
Strategia i przywództwoPrincipal Level
Wyznaczanie kierunku technologicznego całej firmy razem z biznesem, CTO oraz innymi architektami - „Principal” to pozycja ekspercka na poziomie dyrektorskim, ale bez bezpośredniego zarządzania ludźmi (ścieżka IC - Individual Contributor). Taka osoba nie chodzi na spotkania z klientami: jej robota idzie do wewnątrz - spiąć zespół, zdjąć mu z drogi blokady, dopilnować, żeby nie brakowało narzędzi, dostępów ani decyzji.
04
Projektowanie platformyPlatform Architecture
Projektowanie i utrzymywanie platformy, na której stoją wszystkie usługi firmy: klaster Kubernetes, sieć, sekrety, uprawnienia, wdrożenia, chmura pod spodem (AWS, Azure, GCP). Zespół dostaje gotowe środowisko i jedną komendę do wdrożenia, a nie serwer do skonfigurowania.
05
Bezpieczeństwo platformySecurity by default
Wbudowywanie bezpieczeństwa w platformę, zamiast doklejania go audytem na końcu: sekrety w Vaulcie i nigdy w repozytorium, dostęp po najmniejszych potrzebnych uprawnieniach (least privilege), ruch między usługami spięty service meshem (np. Istio, Linkerd) - z szyfrowaniem mTLS i politykami mówiącymi, kto z kim może rozmawiać - a obrazy i zależności skanowane w pipelinie. Podatność łata się wtedy wdrożeniem, a nie zgłoszeniem.
06
Niezawodność i skalowalnośćReliability & Scalability
Definiowanie strategii odporności systemów na awarie (resiliency) i projektowanie ich tak, aby wytrzymywały nagłe skoki ruchu, automatycznie naprawiały się po awarii (self-healing) i spełniały wysokie normy dostępności (np. SLA na poziomie 99,99%).

Gateway API bez magii

data: 2024-10-15
kategoria: Networking
także w: Containers
czytanie: 1 min / 140 słów

Ingress wyglądał jak standard, dopóki standardem nie okazały się adnotacje nginx.ingress.kubernetes.io/*.

To jest punkt startowy tej serii.

Nie "Gateway API jest nowe, więc trzeba je poznać".

Raczej:

text

dlaczego proste API do ruchu HTTP skończyło jako mieszanka YAML-a Kubernetes i konfiguracji konkretnego kontrolera?

Seria ma cztery części.

Pierwsza porządkuje historię od Service przez Ingress do Gateway API. Bez muzeum Kubernetes. Tylko tyle historii, ile trzeba, żeby zobaczyć, dlaczego Ingress nie miał gdzie zmieścić produkcyjnych zachowań.

Druga rozdziela słowo gateway. API gateway, ingress gateway, mesh gateway i Kubernetes Gateway API to nie są zamienne pojęcia.

Trzecia jest o GatewayClass. To miejsce, w którym abstrakcja spotyka się z konkretnym kontrolerem, czyli z decyzją platformową.

Czwarta schodzi do migracji z ingress-nginx: co da się przenieść do standardowego API, co zostaje rozszerzeniem implementacji, czego nie przenosić po cichu i jak testować obok starego kontrolera.

Zaczynamy od problemu, który Gateway API próbuje nazwać lepiej niż Ingress: od Service do Gateway API.