Chmura hybrydowa: on-prem + chmura
1) Dlaczego hybryda i kiedy jest ona uzasadniona
Kierowcy: wymogi regulacyjne (rezydencja danych/PII), istniejące inwestycje on-prem, opóźnienia w systemach „zastrzeżonych”, kontrola kosztów, dostęp do zarządzanych usług w chmurze.
Kompromisy: złożoność sieci i bezpieczeństwo, powielanie kompetencji, synchronizacja danych i konfiguracji, ryzyko operacyjne.
Motto: przenośne, gdzie krytyczne; cloud-native, gdzie jest to opłacalne.
2) Modele hybrydowe
Rozszerzenie on-prem: chmura jako rozszerzenie centrum danych (nowe mikroservice/analityka, fronty).
Cloud-first z miejscowymi kotwicami: rdzeń w chmurze, on-prem - systemy księgowe/bramy płatności/pamięć PII.
Chmura-pękanie: elastyczne szczyty obciążenia w chmurze (partia, promo-piki), objętość podstawy - lokalnie.
DR do Cloud: Hot/Warm Cloud Reserve for on-prem (RTO/RPO managed).
Krawędź + Rdzeń: Węzły PoP/krawędzi są bliżej użytkownika, dane korzeniowe/ML są w chmurze.
3) Sieć i łączność
3. 1 Kanały
Site-to-Site VPN (IPsec/SSL) - start szybko, większa opóźnienie, jitter.
Linie bezpośrednie (DC/ER/IC, MPLS) - przewidywalne SLA, poniżej opóźnienia, droższe.
Dual-link + BGP - tolerancja usterek i kontrola routingu.
3. 2 Adresowanie i trasy
Schemat pojedynczego RFC1918 bez skrzyżowań; Plan CIDR na nadchodzące lata.
Tylko kopuły NAT na granicach; wschód-zachód bez NAT.
Segment/VRF dla izolacji środowisk (dev/stage/prod), najemców, dostawców.
3. 3 Polityka czasu i DNS
Pojedynczy NTP (zegar = los dla kryptografii/podpisów).
Split-horizon DNS: wewnętrzne strefy (svc. klastra. lokalny, corp.local), zewnętrzny - publiczny.
Health-based GSLB dla ruchu przychodzącego.
4) Tożsamość i dostęp
Federacja SSO: OIDC/SAML, on-prem IdP z chmurą IdP; Rezerwa SCIM.
Role zgodnie z zasadą najmniejszego przywileju; Konto na szkło z MSZ.
Identyfikacja maszyny: SPIFFE/SPIRE lub mesh-PKI dla mTLS.
RBAC „end-to-end”: Git/CI/CD → cluster/mesh → brokers/DB → logs.
5) Platforma: Kubernetes + GitOps
5. 1 Pojedyncza warstwa wykonawcza
Klastry on-prem i chmura z tymi samymi wersjami/CRD.
GitOps (Argo CD/Flux): pojedyncze wykresy/nakładki, sterowanie dryfem, strumienie promo.
5. 2 Siatka serwisowa
Istio/Linkerd: domyślny mTLS, równoważenie lokalne, inter-cluster awaryjny.
Zasady L7 (JWT, nagłówki, limity stawek, retry/circuit/timeout) - w kodzie manifestu.
5. 3 Przykład (topologia K8s i siatka)
yaml anti-affinity and distribution by zones on-prem cluster spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }
Istio DestinationRule: local cluster priority, then trafficPolicy cloud:
outlierDetection: { consecutive5xx: 5, interval: 5s, baseEjectionTime: 30s }6) Dane i przechowywanie
6. 1 Podstawy
On-prem master, cloud read-replica (analytics/directories).
Chmura master + on-prem cache (niskie opóźnienie dla lokalnych integracji).
Dystrybuowany SQL/NoSQL (Cockroach/Cassandra) z lokalnymi kworumami.
replikacja CDC/log (Debezium) między pętlami; idempotencja opiekunów.
6. 2 Obiekt/plik/blok
S3-compatible story (on-prem MinIO + S3/GCS w chmurze) z replikacją/wersioning; WORM do audytu.
Kopie zapasowe: 3-2-1 (3 kopie, 2 nośniki, 1 - offsite), regularna weryfikacja odzysku.
6. 3 Pamięć podręczna i kolejki
Klaster Redis/KeyDB na stronę; global cache - tylko poprzez wydarzenia/TTL.
Kafka/Pulsar: MirrorMaker 2/replikator; klucz - deadup/idempotencja konsumentów.
7) Bezpieczeństwo i zgodność (zero zaufania)
mTLS wszędzie (siatka), TLS 1. 2 + na obwodzie; wyłączanie niezaszyfrowanych kanałów.
Tajemnice: HashiCorp Vault/ESO; żetony krótkotrwałe; automatyczna rotacja.
KMS/HSM: klucze oddzielone od jurysdykcji/najemcy; zaplanowane rotacje krypto.
Segmentacja: Polityka, mikro-segmentacja (NSX/Calico), ZTNA dla dostępu administratora.
Dzienniki: immutable (Object Lock), end-to-end 'trace _ id', maskowanie PII/PAN.
8) Obserwowalność, SLO i zarządzanie incydentami
OpenTelemetry SDK wszędzie; Kolektor na prem i w chmurze.
Pobieranie próbek na ogonie: 100% овимовтp99, miejsce etykietowania = onprem 'cloud', 'region', 'tenant'.
Budżety SLO i błędów według szczelin (trasa/najemca/dostawca/strona); wpisy według szybkości spalania.
Deski rozdzielcze typu end-to-end: RED/USE, mapy zależności, porównania kanaryjskie (przed/po migracji).
9) CI/CD i konfiguracje
Pojedynczy rejestr artefaktów (pull-through cache on-prem).
Promo stream: dev → stage (on-prem) → canary (cloud) → prod; lub odwrotnie - w zależności od celu.
Sprawdzanie: testy kontraktowe (OpenAPI/gRPC/CDC), analiza statyczna, łącze IaC, skanowanie obrazu, bramy SLO.
10) DR/BCP (plan ciągłości)
RTO/RPO na usługę. Przykłady:- katalogi/lądowania: RTO 5-15 min, RPO ≤ 5 min;
- płatności/portfele: RTO ≤ 5 min, RPO ≤ 0-1 min (kworum/synchroniczny w miejscu).
- Runbook: przełączanie GSLB/ciężarów, podnoszenie czuwania w klastrze, funkcja-flagi „tryb lekki”.
- GameDays: kwartalny - odłączenie strony/kanału, weryfikacja rzeczywistego RTO/RPO.
11) Koszty i FinOp
Egress między on-prem a chmurą jest głównym „ukrytym” wydatkiem; cache i utrzymywać wędrówki do minimum (SWR, krawędź).
Oznaczanie: „usługa”, „na”, „na miejscu”, „najemca”, „cost _ center”.
Zasada 80/20: przenoszenie/przechowywanie 20% „rdzenia krytycznego”, reszta - gdzie jest tańsze.
Metryki downsampling, odniesienia do dzienników „gorący/zimny”, budget-aware sampling odwzorowanie.
12) Układanie wzorów obciążeń roboczych
13) Przykłady konfiguracji
13. 1 S2S IPsec (pomysł)
onprem ↔ cloud: IKEv2, AES-GCM, PFS group 14, rekey ≤ 1h, DPD 15s, SLA monitoring jitter/packet-loss13. 2 Terraform (tag/etykieta snippet)
hcl resource "kubernetes_namespace" "payments" {
metadata {
name = "payments"
labels = {
"site" = var. site # onprem cloud
"tenant" = var. tenant
"cost_center" = var. cc
}
}
}13. 3 Skarbiec + ESO (secret from on-prem to cloud cluster)
yaml apiVersion: external-secrets. io/v1beta1 kind: ExternalSecret spec:
refreshInterval: 1h secretStoreRef: { kind: ClusterSecretStore, name: vault-store }
target: { name: psp-hmac, creationPolicy: Owner }
data:
- secretKey: hmac remoteRef: { key: kv/data/payments, property: HMAC_SECRET }14) Antypattery
Przecinanie CIDR → chaos NAT; najpierw plan adresowy, potem kanały.
Jedna „wspólna” globalna pamięć podręczna z silną konsystencją → opóźnienie i podział mózgu.
Przekłady bez idempotencji → podwójne odpisy/zamówienia.
„Naga” sieć VPN bez mTLS/Zero Trust wewnątrz - ruch boczny po kompromisie.
Brak ćwiczeń DR: plany nie działają w rzeczywistości.
Rozbieżność między wersjami K8s/CRD/operators → niemożność jednolitych wykresów.
Logowania w wolnym formacie bez 'trace _ id' i maskowania są niemożliwe.
15) Szczegóły dotyczące iGaming/Finance
Miejsce zamieszkania danych: PII/zdarzenia płatnicze - obwód on-prem/regionalny; do chmury - agregaty/anonimowe.
PSP/KYC: wielu dostawców; inteligentne routing z chmury do lokalnych bram, awaryjny do kopii zapasowej; haki przez brokera z deduplikacją.
„Ścieżki pieniężne”: pojedyncze SLO powyżej sumy; HMAC/mTLS, 'Retry-After', 'Idempotence-Key' są wymagane.
Audyt: magazyn WORM (Object Lock), niezmienne dzienniki transakcji, dwukierunkowe nagrywanie (on-prem + cloud) dla zdarzeń krytycznych.
Jurysdykcja: segmentacja klucza KMS/Skarbiec według kraju/marki; geo-bloki na obwodzie.
16) Lista kontrolna gotowości Prod
- Plan adresowy, DNS, NTP - jeden; S2S linki + linki zabezpieczone (BGP).
- Pojedyncza tożsamość (SSO/OIDC/SAML), MFA, najmniejszy przywilej; SPIFFE/SPIRE dla usług.
- K8s we wszystkich obiektach, GitOps, tych samych operatorów/CRD; serwis siatki wg mTLS „locality-aware LB”.
- Dane: CDC, testy spójności, zasady RPO/RTO, 3-2-1 kopie zapasowe i regularne napędy przywracania.
- Bezpieczeństwo: skarbiec/ESO, rotacja, Polityka, ZTNA; kłody są niezmienne.
- Obserwowalność: OTel, pobieranie próbek ogonowych, SLO/budżety według lokalizacji/regionu/najemcy; kanarkowe deski rozdzielcze.
- CI/CD: testy kontraktowe, linking IaC, skanowanie obrazu; bramki uwolnienia przez SLO.
- DR-runbooks, GameDays, zmierzone rzeczywiste RTO/RPO; przyciski cutover/roll-back.
- FinOps: limity, tagi i raporty, mierniki/dzienniki/zasady zatrzymywania tras.
- iGaming szczegóły: rezydencja danych, multi-PSP, audyt WORM, indywidualne SLO płatności.
17) TL; DR
Hybrid = wspólna platforma wykonawcza (K8s + GitOps + mesh + OTel + Vault) na dwóch światach: on-prem i chmurze. Planowanie sieci i tożsamości, przenoszenie danych za pośrednictwem CDC/idempotence, różnicowanie bezpieczeństwa w ramach Zero Trust, pomiar niezawodności budżetów SLO/Error Budgets i pociąg DR. Dla iGaming, przechowywanie danych i płatności w jurysdykcji, korzystanie z multi-PSP inteligentnych routingu i niezmiennego audytu.