GH GambleHub

Operacje i → Zasady realizacji zarządzania i ograniczenia runtime

Zasady realizacji i ograniczenia runtime

1) Cel

Polityka runtime sprawia, że zachowanie usług jest przewidywalne, bezpieczne i ekonomiczne: ograniczyć „hałaśliwe sąsiadów”, zapobiec wyciekom i przegrzaniu, zapewnić zgodność i zachowanie SLO, gdy obciążenie wzrasta.

Główne cele: izolacja, sprawiedliwy przydział zasobów, kontrolowana degradacja, odtwarzalność, audyt.

2) Zakres stosowania

Komputery i pamięć: procesor, pamięć RAM, pauzy GC, limity gwintów.
Dysk/przechowywanie: IOPS/przepustowość, kwoty, fs-polityki (tylko do odczytu).
Сета: egress/ingress, kształtowanie szerokości pasma, zasady sieci.
Procesy/wywołania systemowe: seccomp, możliwości, ulimit.
Orkiestra: Kubernetes QoS, wnioski/limity, priorytety, tains/powinowactwo.
API/bramki: limity stawek, kwoty, terminy/przekładnie, wyłączniki.
Dane/ETL/strumienie: współistnienie partii/strumienia, budżet opóźnienia konsumentów.
Bezpieczeństwo: AppArmor/SELinux, bez korzeni, sekrety/kofigi.
Kod polityki: OPA/Gatekeeper, Kyverno, Conftest.

3) Podstawowe zasady

Fail-safe domyślnie: lepiej upuścić niepotrzebne żądania niż upuścić.
Budget-driven: Timeouts/Retrays wpisuje się w budżet czasu żądania i budżet błędu SLO.
Mały promień wybuchu: przestrzeń nazw/basen/host/izolacja odłamkowa.
Deklaratywne i kontrolne: wszystkie ograniczenia - w kodzie/repozytorium + dziennik zmian.
Uczciwość wielu najemców: żaden najemca/zespół nie może „wysysać” całego klastra.

4) Komputery i pamięć

4. 1 Kubernetes корова v2

wnioski/limity: wnioski gwarantują udział procesora/pamięci; limity obejmują redukcję/zabójcę OOM.
Klasy QoS: Gwarantowane/Pęcherz/Wysiłek - utrzymać krytyczne przepływy pracy w Guaranteed/Burstable.
CPU: 'cpu. akcje „,” cpu. max '(przepustnica), CPuset do szpilek.
Pamięć: 'pamięć. max ',' pamięć. swap. max '(zwykle swap off) oom_score_adj dla priorytetu.

4. 2 Wzory

Głowa 20-30% na węźle, anty-powinowactwo do powielania.
Granice GC: limit pamięci JVM '-Xmx' <k8s; Idź: „GOMEMLIMIT”; Węzeł: '--max-old-space-size'.
ulimit: 'nofile', 'nproc',' fsize '- według profilu serwisowego.

5) Dysk i przechowywanie

IOPS/kwoty przepustowości na PVC/składowanie klastrów; Separacja dziennika/danych.
Tylko do odczytu główny FS, tmpfs dla plików tymczasowych, limit wielkości '/tmp '.
FS-watchdog: wpisy dotyczące napełniania objętościowego i wzrostu wód.

6) Sieć i ruch

Polityka w zakresie zerowego zaufania (ingress/egress) na wschód-zachód.
Ograniczenia przepustowości: zasady tc/egress, QoS/DSCP dla przepływów krytycznych.
Egress controller: lista dozwolonych domen/podsieci, audyt DNS.
Zasady mTLS + TLS - szyfrowanie i wymuszona wersja protokołu.

7) Bezpieczeństwo procesu

Seccomp (syscalls z listy dopuszczalnej), profile AppArmor/SELinux.
Upuść możliwości Linuksa (pozostaw minimum), 'RunAs Root', 'Readunkiem RootFilesystem'.
Pojemniki bez korzeni, podpisane zdjęcia i atesty.
Tajemnice-tylko przez Vault/KMS, tmp-żetony z krótkim TTL.

8) Polityka czasowa: terminy, rekolekcje, budżety

Budżet Timeout: suma wszystkich chmielu ≤ koniec-koniec SLA.
Retrai z backoff + jitter, maksymalne próby w klasie błędów.
Wyłącznik-wyłącznik: otwórz z błędem %/timeout p95 powyżej progu → szybkie awarie.
Grodzie: oddzielne baseny/kolejki połączeń dla ścieżek krytycznych.
Obciążenie zwrotne: ograniczenie producentów do opóźnienia konsumentów.

9) Limity stawek, kwoty i priorytety

Algorytmy: token/wiadro nieszczelne, GCRA; local + distributed (Redis/Envoy/global).
Granularność: klucz API/użytkownik/organizacja/region/punkt końcowy.
Gradienty priorytetowe: przepływy „płatności/autoryzacji” - złoto, analityka - brąz.
kwoty dziennie/miesiąc, limity „wybuchowe” i „trwałe”; 429 + Retry-After.

10) Orkiestra i planista

Klasa : ochrona strąków P1 przed przemieszczeniem.
Budżet PodDis : granice przestojów na aktualizacjach.
Tains/Tolerancje, (anty) Powinowactwo - obciążenia izolacyjne.
Klasa: gVisor/Firecracker/Wasm do piaskownic.
Pozioma/pionowa autoskalarka z progami osłony i maksymalnymi replikami.

11) Polityka dotycząca danych/ETL/Stream

Równoległość na zadanie/temat, maksymalny rozmiar partii, punkt kontrolny.
Opóźnienia budżetowe konsumentów: ostrzeżenie/krytyczne; DLQ i limit retray.
Świeżość SLA dla sklepów, pauza ciężkich miejsc pracy na szczytach ruchu prod.

12) Kodeks polityki i kontrola przyjmowania

OPA Gatekeeper/Kyverno: brak strumieni bez żądań/limitów, brak 'read RootFilesystem', z 'Z siecią', ': najnowszy'.
Przyznaj się do wstępnego zlecenia kontroli Helm/K8s/Terraform.
Zasady mutacji: automatyczne dodawanie sidecar (mTLS), adnotacje, seccompProfil.

Przykład Kyverno - zakaz kontenera bez ograniczeń:
yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: require-resources spec:
validationFailureAction: Enforce rules:
- name: check-limits match:
resources:
kinds: ["Pod"]
validate:
message: "We need resources. requests/limits for CPU and memory"
pattern:
spec:
containers:
- resources:
requests:
cpu: "?"
memory: "?"
limits:
cpu: "?"
memory: "?"
Przykład OPA (Rego) - czasy ≤ 800 ms:
rego package policy. timeout

deny[msg] {
input. kind == "ServiceConfig"
input. timeout_ms> 800 msg: = sprintf ("timeout% dms exceeds budget 800ms," [input. timeout_ms])
}

13) Obserwowalność i wskaźniki zgodności

Zgodność%: procent podeszwy z poprawnymi żądaniami/limitami/etykietami.
Postawa bezpieczeństwa: udział strąków z seccomp/AppArmor/bez korzeni.
Tempo-limit hit%, shed%, przepustnica%, 429 udział.
p95 timeouts/retraces, czas trwania obwodu otwartego.
OOM zabija/eksmisji, CPU przepustnicy sekundy.
Network Egress zaprzeczył zdarzeniom, egress permlist brakuje.

14) Listy kontrolne

Przed wykonaniem usługi

  • Wnioski/limity są pisemne; QoS ≥ Pękające
  • Terminy i przekłady pasują do końcowych SLA
  • Wyłącznik/przegroda włączone dla zewnętrznych zależności
  • W zakresie polityki (ingress/egress) - mTLS
  • Seccomp/AppArmor, możliwości spadku, non-root, tylko do odczytu FS
  • Limity stawek i kwoty na bramę/usługę API
  • PDB/priorytet/powinowactwo określone; skonfigurowano autoskalowanie

Miesięcznie

  • Wyjątki dotyczące polityki audytu (TTL)
  • Czas przeglądu/budżety na błędy
  • Test wiertła pożarowego: szopa/ciśnienie wsteczne/wyłącznik
  • Tajemnice/certyfikaty rotacyjne

15) Anty-wzory

Bez żądań/limitów: „pęknięcie” zjada sąsiadów → wypadki kaskadowe.
Globalne rekolekcje bez jittera: burza uzależnień.
Nieskończone czasy: „wiszące” połączenia i wyczerpanie basenów.
„: najnowsze” i mutable tags: nieprzewidywalne runtime buduje.
Otwarte wyjście: wycieki i bezzałogowe zależności.
Brak PDB: Aktualizacje zniszczyć cały basen.

16) Mini playbooks

A. przepustnica procesora% przy płatnościach-usługach

1. Sprawdź limity/żądania i gorące ścieżki profilu.
2. Tymczasowo podnieść prośby, włączyć autoskale przez opóźnienie p95.
3. Włącz limity/stopy zwrotu gotówki, zmniejszyć złożoność zapytań.
4. Po ustaleniu: denormalizacja/indeksy, zmiana limitów.

B. 429 skargi na wzrost gospodarczy i API

1. Raport na temat kluczy/organizacji → pobiegł do kontyngentu.
2. Wpisz kontyngenty hierarchiczne (per- org → na -key), podnieść pęknięcie dla złota.
3. komunikacja i wskazówki dotyczące backoff; umożliwia adaptacyjne ograniczenie.

B. Masowe zabójstwa OOM

1. Zmniejszyć współistnienie, włączyć limit hałasu i profilowania.
2. Przeliczyć Xmx/GOMEMLIMIT do rzeczywistego szczytowego użycia.
3. Przekładaj GC/baseny, dodaj alerty swap-off i soft-limit.

17) Przykłady konfiguracji

K8s pojemnik z bezpiecznymi ustawieniami (fragment):
yaml securityContext:
runAsNonRoot: true allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities:
drop: ["ALL"]
Limit wskaźnika wysłannika (fragment koncepcyjny):
yaml rate_limit_policy:
actions:
- request_headers:
header_name: "x-api-key"
descriptor_key: "api_key"
Nginx ingress - terminy i ograniczenia:
yaml nginx. ingress. kubernetes. io/proxy-connect-timeout: "2s"
nginx. ingress. kubernetes. io/proxy-read-timeout: "1s"
nginx. ingress. kubernetes. io/limit-rps: "50"

18) Integracja z zarządzaniem zmianami i incydentami

Wszelkie zasady relaksacji jest za pośrednictwem RFC/CAB i tymczasowy wyjątek z TTL.
Incydenty z naruszeniem polityki → aktualizacje pośmiertne i zasady.
Deski rozdzielcze zgodności są podłączone do kalendarza wydania.

19) Najważniejsze

Polityka wykonawcza jest „poręczą” dla platformy: nie przeszkadza w szybkiej jeździe, nie pozwala na upadek. Deklaracyjne ograniczenia, automatyczne egzekwowanie, dobre wskaźniki i dyscyplina wyjątkowa przekształcają chaotyczną eksploatację w zarządzany i przewidywalny system - z kontrolowanymi kosztami i zrównoważonymi SLO.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.