ITQ/RedHat/Esri OpenShift ArcGIS 4 k8s POC

Overleg gehad bij Esri NL over de POC die ITQ, Red Hat en Esri samen hebben uitgevoerd in januari 2026.

Presentatie is hier beschikbaar maar let op Esri heeft gevraagd deze vertrouwelijk te behandelen.

Red Hat gaf aan dat Esri ArcGIS for Kubernetes nog niet gecertificeerd is op OpenShift, nagegaan wordt of Esri dit van plan is en op wat voor termijn. Mendix is bijvoorbeeld wel gecertificeerd. Red Hat gaf ook nog de tip om dit eventueel op te nemen in de vorm van bonuspunten bij aanbestedingen.

Er is gekeken naar Haven (onderdeel van common ground) voor security compliancy, meeste problemen komen voort uit dat het een dev cluster profiel is, er wordt vanuit gegaan dat alle problemen oplosbaar zijn sowieso, maar dat was nu niet de focus van de POC.

Ze hebben ook getest in een disconnected omgeving, met een lokale container registry (Haven), dit ging op zich goed.

Ze hebben gebruik gemaakt van Helm voor de deployment.

Development profiel van ArcGIS for kubernetes. OpenShift 4.19.21, ArcGIS 12.0.0.7286.

Per node in het cluster is eigenlijk 200 Gb storage nodig de images zijn best groot en de ephemeral storage wordt daar ook opgeslagen. In de POC hadden ze maar 500 Gb totaal dus dat was eigenlijk te weinig.

Ze hebben ook getest met upgrades, zowel van OpenShift als ArcGIS. Er was downtime maar dat was verwacht omdat in het dev profiel niet alles dubbel uitgevoerd is. Bij een productie cluster zou er geen downtime zijn, maar wel een periode waarin het platform in read-only modus draait.

Ze gebruikten VMWare op IBM hardware.

Bij RWS krijgen we hosted control planes als design dus is misschien anders? Virtuele clusters?

Dedicated cluster waarbij je meer controle hebt over de onderliggende OpenShift versie wordt geopperd als mogelijkheid om mogelijke versie problemen tussen wat Esri ondersteunt aan OpenShift op te lossen.

Voor de relational datastore is er geen ondersteuning voor een private PostgreSQL of private s3 buckets, alleen voor de hyperscaler varianten. Hier hebben ze omheen gewerkt voor PostgreSQL via Google AlloyDB en dan de connectie string aanpassen voor PostgreSQL, maar dit is geen ondersteunde workaround. Het is aangemeld bij Esri Inc. Voor S3 was er geen workaround omdat er automatisch suffixen werden toegevoegd. Lijkt erop dat de focus vooral gelegen heeft bij public cloud en niet zo zeer bij private cloud tot nu toe. Voor EGDB (enterprise geodatabase) is er geen probleem en kan ook met EnterpriseDB worden gewerkt.

Bij Harbor was er een probleem met $ in de username, bug is ook aangemeld. Maar bij RWS gaan we met quay werken.

Er was een probleem met certificaten bij gebruik van de OpenShift routes. Het precheck script van Esri stopt omdat het secret niet gevonden wordt. Er is gevraagd aan Esri Inc voor een flag zodat dit niet de precheck stopt. Ze hebben het wel werkend gekregen, maar was niet ideaal. Je kan zelf certificaten genereren en meegeven aan deployment, maar de koppeling is lastig. Of alles met certificaten aan de ArcGIS kant neerleggen maar dan heb je weer geen ACME bijvoorbeeld. Dit is dus zeker een aandachtspunt binnen de RWS POC.

ArgoCD is niet mogelijk, deployment loopt via jobs only. Dus wel bijvoorbeeld tekton of gitlab pipeline. GitOps is niet mogelijk. Je kan wel bijvoorbeeld Helm upgrade vanuit een pipeline aftrappen.

Er waren wat security issues (omdat OpenShift standaard erg dicht staat), maar die zijn wel opgelost. ArcGIS ging bijvoorbeeld uit van een hardcoded range ergens. In de ogen van ITQ bracht dit de security verder niet in gevaar, het was alleen niet zo flexibel als ze gehoopt hadden.