Infrastruktura

Wymagania sprzętowe EZD RP — Kubernetes, bazy, repozytoria

Komponenty wymagane do produkcyjnego uruchomienia EZD RP: klaster Kubernetes (RKE2), PostgreSQL/MS SQL, Redis, RabbitMQ, NFS/MinIO, backup. Minimalne, rekomendowane i konkretne konfiguracje dla 3 skal jednostek.

Stan na 2026-05-13 • Bazujemy na oficjalnych źródłach NASK / gov.pl

Oficjalny podręcznik NASK definiuje komponenty wymagane dla środowiska produkcyjnego EZD RP. Poniżej praktyczny przegląd architektury, minimalnych wymagań i konkretnych konfiguracji dla trzech skal jednostek (mała / średnia / duża).

Komponenty obowiązkowe

  • Klaster Kubernetes — najczęściej RKE2 lub vanilla K8s (minimum 3 węzły dla HA)
  • Baza danych relacyjna — PostgreSQL lub MS SQL Server (wersja zgodna z aktualną dokumentacją NASK)
  • Cache — Redis (typowo standalone lub w konfiguracji sentinel)
  • Kolejki komunikatów — RabbitMQ (cluster 3-node dla HA)
  • Repozytorium plików — NFS (najprostsze) lub kompatybilny z S3 (np. MinIO — rekomendowane dla większej skali)
  • Reverse proxy + SSL — nginx ingress / HAProxy z certyfikatami TLS
  • Backup + Storage Class — odpowiednia polityka snapshotów dla bazy i repozytorium
Jednowęzłowy Kubernetes — nie na produkcję
Oficjalne scenariusze NASK podkreślają, że jednowęzłowe środowisko Kubernetes nie jest zalecane produkcyjnie z uwagi na brak HA i odporności na awarię węzła. Akceptowalne tylko w środowisku DEV/TEST.

Konfiguracje referencyjne (3 skale)

Mała jednostka — do 50 użytkowników (gmina wiejska, mała szkoła)

KomponentKonfiguracjaUwagi
Klaster Kubernetes3× węzeł (8 vCPU / 16 GB RAM / 200 GB SSD)RKE2, najprostsze ze stabilnych
PostgreSQL1× instancja (4 vCPU / 8 GB RAM / 100 GB SSD)Bez replikacji — backup wystarcza
Redis1× standalone (2 vCPU / 2 GB RAM)Brak konieczności sentinel
RabbitMQ1× standalone (2 vCPU / 2 GB RAM)Wystarczy 1 instancja
RepozytoriumNFS (1 TB)Prosto, łatwo backupować
BackupCodzienny dump bazy + snapshot NFSRetencja 30 dni

Średnia jednostka — 50-300 użytkowników (gmina średnia, powiat, szpital)

KomponentKonfiguracjaUwagi
Klaster Kubernetes5× węzeł (16 vCPU / 32 GB RAM / 500 GB SSD)3× control plane + 2-3× worker
PostgreSQLKlaster Patroni (1 primary + 1-2 standby)Replikacja synchroniczna
RedisSentinel (3 instancje)Failover automatyczny
RabbitMQCluster 3-nodeMirrored queues
RepozytoriumMinIO (4 dyski, 4-8 TB)Distributed mode
BackupContinuous WAL archiving + snapshot MinIORPO < 15 min, RTO < 2 h

Duża jednostka — 300-2000+ użytkowników (urząd wojewódzki, ministerstwo, duża grupa JST)

KomponentKonfiguracjaUwagi
Klaster Kubernetes9+× węzeł (32 vCPU / 64 GB RAM / 1 TB NVMe)3× CP + 6+× worker, multi-AZ
PostgreSQLKlaster Patroni 3+ node + read replicasFailover < 30s, replikacja synchroniczna
RedisSentinel 3-node + read replicasFailover automatyczny
RabbitMQCluster 5-nodeQuorum queues
RepozytoriumMinIO klaster (8+ dysków, 20+ TB)Erasure coding
BackupContinuous WAL + snapshoty + offsiteRPO < 5 min, RTO < 1 h
MonitoringPrometheus + Grafana + Loki + AlertManagerPagerDuty/email alerty

Wymagania sieciowe

  • Łącze internetowe — minimum 100 Mbit symetryczne, dla dużych jednostek 1 Gbit+
  • Latencja do KSeF / e-Doręczeń / ePUAP — kluczowa, sprawdzić przed wdrożeniem
  • Firewall / WAF — przed reverse proxy, polityki dla ruchu publicznego
  • Wewnętrzny DNS — dla wewnętrznej komunikacji między usługami
  • Certyfikaty SSL — Let's Encrypt (auto-renew) lub komercyjne dla domen instytucjonalnych

Backup, RTO, RPO — minima

Polityka backup do udokumentowania przed startem
  • RPO (Recovery Point Objective) — ile maks. danych można stracić; typowo 15 min – 1 h
  • RTO (Recovery Time Objective) — w jakim czasie odtworzyć system; typowo 2-4 h
  • Codzienny pełny backup bazy + repozytorium
  • Continuous WAL archiving (dla PostgreSQL) — recovery do dowolnego punktu w czasie
  • Replikacja offsite (drugie centrum / chmura)
  • Test odtwarzania min. raz na kwartał — backup bez testu = brak backup'u
Źródła oficjalne
Audyt środowiska technicznego

Sprawdzimy, czy Wasza obecna infrastruktura wystarczy, co trzeba douzupełnić i ile to realnie kosztuje.

Umów audyt

Najczęstsze pytania

Czy można uruchomić EZD RP na zwirtualizowanym środowisku (VMware, Proxmox)?

Tak — większość wdrożeń on-premise pracuje na maszynach wirtualnych (VMware vSphere, Proxmox, KVM). Klaster Kubernetes działa identycznie.

Czy potrzebujemy dedykowanego storage'u (SAN)?

Nie obowiązkowo. Dla małej i średniej skali wystarczy lokalny SSD na węzłach + NFS dla repozytorium. SAN ma sens dla dużych wdrożeń z wymogami HA i throughput.

Jakie dokładnie wersje PostgreSQL / MS SQL są wspierane?

Lista wspieranych wersji jest w aktualnej dokumentacji NASK i może się zmieniać między release'ami EZD RP. Zawsze sprawdzaj przed instalacją na podręczniku z gov.pl.

Czy potrzebujemy ekspertów Kubernetes wewnątrz organizacji?

Tak, jeśli wybieramy on-premise. Zatrudnienie / outsourcing minimum 1 osoby z doświadczeniem K8s jest praktycznie niezbędne. Dla SaaS — całość po stronie dostawcy.

Czytaj dalej

Model: on-premise
EZD RP on-premise — instalacja we własnej infrastrukturze
On-premise: pełna kontrola nad infrastrukturą i konfiguracją EZD RP — kosztem zespołu IT i serwerów. Dla kogo ma sens, architektura referencyjna, ścieżka wdrożenia, koszty i ryzyka.
Wybór modelu
Modele wdrożenia EZD RP — SaaS, on-premise, Private SaaS
Trzy modele uruchomienia EZD RP — porównanie kosztów, czasu wdrożenia, możliwości integracji, zakresu kontroli i typowych ryzyk. Dla kogo SaaS, dla kogo on-premise, kiedy Private SaaS.
Wdrożenie
Wdrożenie EZD RP krok po kroku — przewodnik dla urzędu
Pełny proces wdrożenia EZD RP — od decyzji i audytu, przez konfigurację i integracje, po szkolenia i start produkcyjny. Etapy, role w zespole, ryzyka, harmonogram.