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