Vanaf woensdag 10 april wordt de CHP5 Testomgeving in beta beschikbaar gesteld aan al onze afnemers. Vanaf dat moment is het mogelijk om in te loggen op de nieuwe omgeving en workloads te starten als test om na te gaan of er grote problemen naar boven komen. Dit vervangt een deel van de huidige CHP4 omgeving (waar geen onderscheid in test en produktie is gemaakt). De “test” workloads in het huidige CHP4 cluster zullen hun nieuwe thuis op dit CHP 5 testcluster moeten vinden. In de beta periode behouden wij ons nog wel het recht voor om het cluster nog opnieuw te installeren mocht hier aanleiding voor zijn. Inloggen op deze omgeving kan via https://console.chp5-test.npocloud.nl, inloggen gaat ook hier via onze SSO omgeving, nieuwe credentials zijn daarom niet nodig. Uiteraard horen we het graag wanneer er problemen opgemerkt worden.

Vanaf 1 mei is deze omgeving, samen met de nieuwe productieomgeving definitief.

Onderstaande een overzicht van de belangrijkste wijzigingen in CHP5:

In CHP5 gaan we, zoals aangekondigd, werken met 2 clusters in plaats van 1 cluster. We splitsen de clusters op in een test- en productiecluster. Doordat we 2 clusters hebben, zullen we ook 2 consoles hebben, met elk een eigen URL:

• Voor productie: https://console.chp5-prod.npocloud.nl
• Voor test: https://console.chp5-test.npocloud.nl

De oude console url (console.chp4.io) komt te vervallen na de migraties.

In OpenShift worden er routers gebruikt om workloads beschikbaar te maken vanaf het internet. Alle afnemers hebben hun eigen set routers in CHP4, en dat zal in CHP5 niet veranderen. Alle afnemers krijgen wel in CHP5 twee sets routers, een voor test en een voor productie.

De URL's van deze routers veranderen ook, nu is dat .apps.xrtv.cluster.chp4.io, in CHP5 wordt dat:

• Voor productie: .apps.xrtv.cluster.chp5-prod.npocloud.nl
• Voor test: .apps.xrtv.cluster.chp5-test.npocloud.nl

In CHP4 draaien de routers nog op hun eigen nodes. In CHP5 zullen deze gaan draaien op de bestaande infra nodes. Op de testomgeving zijn dat er 3 en in productie 6.

Dat betekent dat op de testomgeving we 3 Replica's per router-set aanbieden en op de productieomgeving 6. Mocht er meer capaciteit nodig zijn, dan zullen we eerst in de routers zelf gaan schalen voordat we replica's gaan bijschalen.

In CHP4 maken we gebruik van een stack van ElasticSearch, FluentD en Kibana voor het opslaan en inzichtelijk maken van logbestanden van Pods, binnen deze stack hebben we een logretentie van 7 dagen. Met CHP5 zal deze stack worden vervangen door Loki, Vector en een Console Plugin. Loki zal gebruikt worden voor de opslag van de logging. Loki heeft de functionaliteit om de logs in S3 op te slaan. Vector vervangt FluentD en zal verantwoordelijk zijn voor het versturen van de logs naar Loki. Kibana wordt vervangen door een Plugin in de OpenShift Console. Logs in CHP5 zijn terug te zien in de Console, in de “Developer” view, onder “Observe”, en dan “Logs”. Met de introductie van deze stack kunnen we ook de retentie van de logs omhoog schroeven naar 31 dagen.

Qua monitoring is er weinig veranderd. We verhogen de retentie van 14 dagen naar 31 dagen. Wel zijn er wat aanpassingen gedaan in de User Workload Monitoring. Hier is momenteel de retentie van de metrics ingesteld op 24 uur, dit wordt verhoogd naar 31 dagen. Daarnaast is er ook een eigen Alert Manager voor de User Workload Monitoring. Meer informatie hierover is te vinden in de documentatie van OpenShift: https://docs.openshift.com/container-platform/4.14/monitoring/managing-alerts.html#managing-alerting-rules-for-user-defined-projects_managing-alerts

In CHP5 zullen we storage aanbieden op dezelfde manier als in CHP4, met OpenShift Data Foundation (ODF). Wel hebben we de standaard “StorageClass” aangepast.

Binnen OpenShift hebben we 2 StorageClasses:

• ocs-storagecluster-cephfs, deze class is vooral bedoeld voor storage die door meerdere pods tegelijk benaderd moet kunnen worden (RWX), bijvoorbeeld voor PHP code die beschikbaar moet zijn in meerdere containers tegelijk.
• ocs-storagecluster-ceph-rbd, deze class is bedoeld voor storage die door maximaal 1 Pod tegelijk benaderd hoeft te worden (RWO), databases bijvoorbeeld.

In CHP4 is de CephFS StorageClass de standaard optie. Het probleem hierbij is dat veel databases die via de console zijn samengesteld deze StorageClass zijn gaan gebruiken waardoor het CephFS gedeelte van de Storage onnodig extra belast werd. In CHP5 hebben we de standaard daarom op Ceph-RBD ingesteld. Dit betekent wel dat het nodig kan zijn om aanpassingen te doen in de yaml configuratie van de Persistent Volume Claim. Als de PVC gebruik moet maken van de CephFS storageclass, dan moet daar een StorageClassName aan toegevoegd worden:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: ocs-storagecluster-cephfs  <<-- Deze moet worden toegevoegd.
  volumeMode: Filesystem

In CHP4 heeft elk project een eigen quota gekregen voor de resources die in dat project maximaal gebruikt mogen worden. Dit concept zal worden vervangen door een “ClusterResourceQuota”. Dit is een quota die over alle projecten per afnemer gedeeld kan worden. Zo verwachten we dat het minder vaak nodig is om quota aanpassingen te laten uitvoeren.

Ook in de Limits hebben we aanpassingen gedaan, met name de Default Request. Dit zijn de Resources die een workload krijgt op het moment dat deze niet expliciet worden geconfigureerd. In CHP4 is dit geconfigureerd op 100m CPU en 128Mi Memory. In CHP5 is dit aangepast naar 10m CPU en 10M Memory. Het is bij de migraties dus belangrijk om te kijken of er Resources zijn geconfigureerd in de workloads, en wanneer dat niet het geval is moeten deze geconfigureerd worden.

Vanaf CHP5 is de DeploymentConfig resource deprecated. Dat betekent dat deze functionaliteit op termijn helemaal uitgefaseerd zal worden. Hoewel de functionaliteit nog wel blijft bestaan in CHP5, willen we iedereen die dit nog gebruikt sterk adviseren deze om te schrijven naar een Deployment. Informatie hierover is hier te vinden: https://access.redhat.com/articles/7041372.

In CHP5 zal netwerkverkeer tussen de verschillende projecten standaard niet mogelijk zijn. Dit wordt dicht gezet via Network Policy's. Deze Policy's kunnen door de afnemers zelf worden aangepast. Er is echter wel een risico dat het Project beschikbaar wordt vanuit Projecten van andere afnemers wanneer dit niet goed geconfigureerd wordt. Advies hierover kan worden ingewonnen bij NPO Hosting.

In CHP4 wordt er gebruik gemaakt van de “openshift-acme” controller om SSL Certificaten aan te vragen. Deze tool werd al langer niet meer ondersteund en doorontwikkeld, en we hebben deze daarom ook vervangen door een implementatie van cert-manager. Het is nog steeds mogelijk om met een annotation op een Route automatisch een SSL certificaat aan te laten maken. Dat moet in CHP5 gebeuren met de volgende annotations:

  annotations:
    cert-manager.io/issuer-kind: ClusterIssuer
    cert-manager.io/issuer-name: letsencrypt-production

We hebben een aantal aanpassingen gedaan in de naamgeving van de groepen om wat meer overzicht te krijgen. We hebben voor CHP5 gekozen voor de volgende structuur:

• xrtv-intern: groep met alle interne medewerkers van een afnemer, deze groep mag ook projecten aanmaken.
• xrtv-extern-$bedrijf: groep met eventuele externe developers van een afnemer, waar $bedrijf wordt vervangen door de bedrijfsnaam van de developers. Deze groep kan standaard geen projecten aanmaken.

Neem bij vragen of opmerkingen contact op via de reguliere kanalen.