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)
| Komponent | Konfiguracja | Uwagi |
|---|---|---|
| Klaster Kubernetes | 3× węzeł (8 vCPU / 16 GB RAM / 200 GB SSD) | RKE2, najprostsze ze stabilnych |
| PostgreSQL | 1× instancja (4 vCPU / 8 GB RAM / 100 GB SSD) | Bez replikacji — backup wystarcza |
| Redis | 1× standalone (2 vCPU / 2 GB RAM) | Brak konieczności sentinel |
| RabbitMQ | 1× standalone (2 vCPU / 2 GB RAM) | Wystarczy 1 instancja |
| Repozytorium | NFS (1 TB) | Prosto, łatwo backupować |
| Backup | Codzienny dump bazy + snapshot NFS | Retencja 30 dni |
Średnia jednostka — 50-300 użytkowników (gmina średnia, powiat, szpital)
| Komponent | Konfiguracja | Uwagi |
|---|---|---|
| Klaster Kubernetes | 5× węzeł (16 vCPU / 32 GB RAM / 500 GB SSD) | 3× control plane + 2-3× worker |
| PostgreSQL | Klaster Patroni (1 primary + 1-2 standby) | Replikacja synchroniczna |
| Redis | Sentinel (3 instancje) | Failover automatyczny |
| RabbitMQ | Cluster 3-node | Mirrored queues |
| Repozytorium | MinIO (4 dyski, 4-8 TB) | Distributed mode |
| Backup | Continuous WAL archiving + snapshot MinIO | RPO < 15 min, RTO < 2 h |
Duża jednostka — 300-2000+ użytkowników (urząd wojewódzki, ministerstwo, duża grupa JST)
| Komponent | Konfiguracja | Uwagi |
|---|---|---|
| Klaster Kubernetes | 9+× węzeł (32 vCPU / 64 GB RAM / 1 TB NVMe) | 3× CP + 6+× worker, multi-AZ |
| PostgreSQL | Klaster Patroni 3+ node + read replicas | Failover < 30s, replikacja synchroniczna |
| Redis | Sentinel 3-node + read replicas | Failover automatyczny |
| RabbitMQ | Cluster 5-node | Quorum queues |
| Repozytorium | MinIO klaster (8+ dysków, 20+ TB) | Erasure coding |
| Backup | Continuous WAL + snapshoty + offsite | RPO < 5 min, RTO < 1 h |
| Monitoring | Prometheus + Grafana + Loki + AlertManager | PagerDuty/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
Sprawdzone: 30 maja 2026
- Podręcznik użytkownika EZD RP →gov.pl / NASK
- Dokumenty wdrożeniowe EZD RP →gov.pl / NASK
- EZD RP — gov.pl →gov.pl / NASK
Audyt środowiska technicznego
Sprawdzimy, czy Wasza obecna infrastruktura wystarczy, co trzeba douzupełnić i ile to realnie kosztuje.
Umów audytWsparcie wdrożeniowe
Potrzebujesz wsparcia we wdrożeniu lub konfiguracji? Skontaktuj się z zespołem Lynx360 — bezpłatna pierwsza konsultacja.
Powiązane źródła oficjalne
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.