Mēs Devs.lv esam pārvaldījuši 50+ Kubernetes klasterus dažādās nozarēs — no fintech līdz e-komercijai. Šīs ir 5 biežākās kļūdas, ko redzam atkal un atkal, un konkrēti padomi, kā tās novērst.
1. Nav resursu limitu — resursu izolācijas problēma
Bez CPU/memory limitiem viens pods var patērēt visus noda resursus. Rezultāts — citi podi sāk saņemt OOMKill vai CPU throttle, un jūsu produkcijas serviss palēninās bez skaidra iemesla.
Risinājums:
- Vienmēr definējiet
resources.requestsunresources.limitskatram konteineram - Sāciet ar
requests: cpu: 100m, memory: 128Miun pielāgojiet pēc reālās slodzes datiem - Izmantojiet
LimitRangeunResourceQuotanamespace līmenī kā aizsardzības tīklu - Uzstādiet monitoringu ar Prometheus + Grafana, lai redzētu faktisko resursu patēriņu
2. Viena replika bez redundances
Deployment ar replicas: 1 nav gatavs produkcijai. Ja šis vienīgais pods avarē vai nods tiek restartēts, jūsu serviss ir nepieejams. Pat dažu sekunžu dīkstāve var nozīmēt zaudētus pasūtījumus vai klientu neapmierinātību.
Risinājums:
- Minimums — 3 replikas katram production deployment
- Konfigurējiet
podAntiAffinity, lai replikas atrastos uz dažādiem nodiem - Izmantojiet
PodDisruptionBudget(PDB), lai garantētu minimālo repliku skaitu nodu uzturēšanas laikā - Apsveriet
topologySpreadConstraintssadalījumam starp pieejamības zonām
3. Nav konfigurētu health checks
Bez liveness un readiness probes Kubernetes nevar noteikt, vai jūsu aplikācija darbojas pareizi. Pods var būt "Running" statusā, bet serviss iekšēji ir iesalis vai neapkalpo pieprasījumus.
Risinājums:
- Readiness probe — nosaka, kad pods ir gatavs saņemt trafiku. Bez tā Kubernetes sūta trafiku uz vēl negataviem podiem.
- Liveness probe — nosaka, vai pods ir "dzīvs". Ja nē, Kubernetes to restartē automātiski.
- Startup probe — lietojiet aplikācijām ar garu starta laiku (Java, .NET), lai liveness probe nesāk nogalināt lēni startējošus podus.
- HTTP endpoint ir labāks par TCP check —
/healthzvai/readyvar pārbaudīt datubāzes savienojumu un citas atkarības.
4. Sekreti YAML failos bez šifrēšanas
Kubernetes Secrets ir tikai base64 kodēti, nevis šifrēti. Ja tos iekļaujat Git repozitorijā, jebkurš ar piekļuvi var tos nolasīt. Mēs esam redzējuši datubāzu paroles, API atslēgas un pat privātos sertifikātus publiskos Git repozitorijos.
Risinājums:
- External Secrets Operator — sinhronizē sekretus no AWS Secrets Manager, HashiCorp Vault vai Azure Key Vault tieši Kubernetes klasterī
- Sealed Secrets — šifrē sekretus ar publisko atslēgu, lai tos varētu droši glabāt Git
- SOPS — Mozilla rīks YAML/JSON failu šifrēšanai ar KMS vai PGP
- Pievienojiet
.gitignoreierakstus unpre-commit hooks, kas novērš nejaušu sekretu iekļaušanu repozitorijā
5. Nav network policies — neierobežota tīkla piekļuve
Pēc noklusējuma visi podi var komunicēt ar visiem citiem podiem klasterī. Tas nozīmē, ka kompromitēts pods staging namespace var piekļūt production datubāzei. Viena ievainojamība var novest pie pilnīga klastera kompromitēšanas.
Risinājums:
- Sāciet ar "deny all" default policy katram namespace
- Atveriet tikai nepieciešamos savienojumus — piemēram, frontend → backend → database
- Izmantojiet namespace izolāciju — production, staging un development nekad nedrīkst komunicēt savā starpā
- Apsveriet service mesh (Istio, Linkerd), ja nepieciešama mTLS un detalizēta trafika kontrole
Bonuss: monitoringa trūkums
Daudzi uzstāda Kubernetes un aizmirst par monitoringu. Bez metrikām un alertiem jūs uzzināsiet par problēmām tikai tad, kad klients ziņo par kļūdu.
Minimālais monitoringa steks: Prometheus + Grafana + Alertmanager. Pievienojiet Loki žurnālu analīzei un Jaeger vai Tempo distribuēto trasēšanai.
Secinājums
Šīs kļūdas ir vienkārši novēršamas, bet tās izraisa 80% produkcijas incidentu, ko mēs redzam. Lielākā daļa ir preventīvas darbības, kas aizņem dažas stundas, bet pasargā no naktīm pavadītām incidentu risināšanā.
Vēlaties Kubernetes drošības auditu? Mēs varam pārbaudīt jūsu klasterī 2-3 dienu laikā un sniegt konkrētu rekomendāciju plānu.