Netwerk, ingang en verkeer tussen diensten

Het clusterbeheer staat in de zone platform (vrf-platform). Iedere server heeft één bundel van 2 × 100 Gb over het leaf-paar van zijn rek, met VLAN 610 ongetagd op br-ex (MTU 1500). De besturingsknooppunten zijn alleen op VLAN 610 aangesloten, de werkerknooppunten ook op VLAN 622 voor de objecttoegang, en iLO heeft een eigen poort in VLAN 600. Werkers bereiken het clusterbeheer alleen op API-adressen (TCP 6443) en ingangsadressen (TCP 443), de externe verkeersverdeling alleen op API-adressen en de aanmeldingang.

Alle adressen van het clusterbeheer komen uit het segment van VLAN 610 (cel 1: 10.61.10.0/24), ook een reeks van 32 API-adressen voor gehoste clusters met een deelreeks voor de herstelzone, die netwerkbeheer in Infoblox en NetBox reserveert. MetalLB op het clusterbeheer (IPAddressPool en L2Advertisement) kondigt ieder adres in laag 2-modus aan vanaf één werkerknooppunt en verplaatst het bij uitval. Vanaf groeipadstap 3 gaat MetalLB over op BGP via FRR-K8s, met dezelfde adressen.

Het clusterbeheer van cel 1 heet c1-cb-01, met api.c1-cb-01.c1.dc3.internal en *.apps.c1-cb-01.c1.dc3.internal. Ieder gehost cluster krijgt api.<naam>.<cel>.dc3.internal en oauth.<naam>.<cel>.dc3.internal, vóór het aanmaken in Infoblox vastgelegd in twee weergaven: werkersegmenten en de zones platform, herstel en beheer krijgen het adres op het clusterbeheer, anderen het virtuele adres van de externe verkeersverdeling.

Achter het API-adres verdeelt de besturing het verkeer over drie API-servers; de routes lopen via het ingangsadres van het clusterbeheer, dat keepalived en haproxy in het cluster verzorgen. De aanmeldroute van ieder gehost cluster heeft een vaste hostnaam in de clusterdefinitie. Teams bereiken haar via de aanmeldingang: een eigen ingangscontroller met een vast adres uit de reeks van 32, die alleen de besturingsnaamruimten buiten de herstelzone bedient (OAuth, Konnectivity en Ignition). Console en standaardingang van het clusterbeheer blijven zo voor teams onbereikbaar.

Besturingen in de herstelzone krijgen een API-adres uit de deelreeks en een eigen ingangscontroller, een LoadBalancer met een ingangsadres uit dezelfde deelreeks; de standaardingang neemt hun naamruimten niet op. Vanuit de herstelzone (VLAN 690) zijn op het clusterbeheer alleen die adressen bereikbaar, op TCP 6443 en 443.

API, aanmelding en routes zijn alleen met TLS bereikbaar, afgesloten op het clusterbeheer. Cert-manager geeft de certificaten uit onder de tussen-CA van de cel: voor API en ingangen van het clusterbeheer, en per gehost cluster voor de API-hostnaam en de aanmeldroute. Zij gelden ten hoogste 2160 uur en worden na twee derde van de looptijd vernieuwd. De interne keten van de besturing blijft voor haar interne verbindingen; de interne API-naam krijgt geen eigen certificaat. Het TLS-profiel is Modern waar alle clients dat ondersteunen, anders Intermediate.

Het clusterbeheer heeft alleen de vaste verbindingen in de tabel.

Ieder applicatiecluster heeft een eigen VLAN voor werkers, ingangsadres en databaseadressen, met een /26 in het routeringsdomein van zijn profiel: VLAN 1000–1499 in vrf-afn-p1, 1500–1899 in vrf-afn-p2 en 1900–1999 in vrf-afn-p3, met MTU 9000. Een gehost cluster met een platformfunctie krijgt een eigen VLAN uit 700–709 met een /26 in vrf-platform. Netwerkbeheer wijst het VLAN toe en registreert het.

Pod- en dienstadressen worden niet gerouteerd; verkeer verlaat het cluster via de werkers. Alleen werkers van een cluster met volumes hebben een tweede aansluiting op het opslagclientnetwerk (VLAN 620), met een statisch adres uit de clusterdefinitie. Die aansluiting valt buiten het netwerkbeleid van het cluster; toegangslijsten op de leaf begrenzen haar.

Een applicatiecluster heeft alleen de vaste verbindingen in de tabel; ander verkeer naar buiten volgt de gedeclareerde verbindingen uit de dienstbeschrijving.

De namen api.<naam>.<cel>.dc3.internal en *.apps.<naam>.<cel>.dc3.internal wijzen naar twee virtuele adressen van de externe verkeersverdeling, die Infoblox en NetBox vóór de publicatie kennen. De verkeersverdeling geeft het verkeer door zonder TLS-afsluiting of certificaatcontrole: TCP 6443 naar het API-adres op het clusterbeheer en TCP 443 naar het ingangsadres van het cluster, waar de API-server of de ingang TLS afsluit. Een andere poort, zoals 5432 voor replicatie in bedrijfskritische productie, krijgt per gedeclareerde verbinding een eigen virtueel adres met TCP-doorgifte naar een LoadBalancer-dienst in het clustersegment.

Ieder applicatiecluster heeft één ingangsadres in het VLAN van zijn werkers: MetalLB in het gastcluster (IPAddressPool en L2Advertisement, via beleid) met de standaardingangscontroller als LoadBalancer-dienst. De ingangscontroller sluit TLS af met het standaardcertificaat *.apps.<naam>.<cel>.dc3.internal van cert-manager onder de tussen-CA van de cel en met het TLS-profiel van de baseline; beleid zet HSTS op iedere route. De ingang ziet als bron het adres naar achteren van de verkeersverdeling, zonder X-Forwarded-For, en begrenst het aanvraagtempo.

Van buiten is een applicatiecluster alleen bereikbaar via de externe verkeersverdeling. Hostnetwerk en secundaire interfaces krijgt een werklast alleen als de dienstbeschrijving ze vermeldt, en de opslagaansluiting alleen bij volumes en nooit in de herstelzone.

Het beheerdersbeleid (AdminNetworkPolicy) beschermt het platform en scheidt afnemers, met voorrang boven het netwerkbeleid van teams; het basisbeleid (BaselineAdminNetworkPolicy ‘default’) weigert als vangnet het overige verkeer. Het vlootbeheer dwingt beide af. NetworkPolicies van teams komen uit de dienstbeschrijving en staan alleen gedeclareerde verbindingen toe.

Pods bereiken buiten het cluster alleen gedeclareerde bestemmingen, na zonecontrole, en nooit de adresreeksen van missiekritieke zones buiten de voorgeschreven koppelvlakken. Iedere teamnaamruimte heeft een EgressFirewall ‘default’ met een afsluitende weigerregel; geweigerd verkeer wordt vastgelegd via ACL-logging en gaat naar het SOC.

Zolang het dienstennetwerk er niet is, gelden het netwerkbeleid tussen naamruimten en versleuteling door de toepassing zelf, als uitzondering met einddatum. Een tussenvorm wordt niet ingevoerd: de leverancier ondersteunt de gemeenschappelijke besturing met aangesloten clusters in de gekozen versie alleen met een extra container per toepassing, en de lichte vorm alleen met een besturing per cluster en dan als voorlopige functie.

Zonder dienstennetwerk versleutelt de toepassing haar verkeer zelf, en is iedere onversleutelde stroom een eigen uitzondering van ten hoogste zes maanden in het uitzonderingsregister, geaccepteerd door de CISO-functie. Bij de vrijgave voor reguliere productie wordt zo’n uitzondering gesloten of opnieuw geaccepteerd met een nieuwe einddatum. Met dienstennetwerk is het verkeer wederzijds herkend, met ten minste TLS 1.3 versleuteld en per applicatie-identiteit toegestaan.

In de doelsituatie herkent het dienstennetwerk voor het verkeer tussen aangesloten naamruimten de tegenpartij aan een identiteit per werklast en versleutelt het automatisch, zonder aanpassing van de code. Eén gedeelde component per werker doet dat voor alle toepassingen op die werker, zodat toepassingen niet opnieuw starten als het dienstennetwerk wordt ingeschakeld of bijgewerkt. De applicatieclusters van een cel sluiten aan op één besturingscluster per cel, een gewoon gehost cluster uit het aanbod; zo vormt iedere cel één dienstennetwerk met een eigen vertrouwensdomein onder haar tussen-CA, en scheiden regels per applicatie-identiteit en het netwerkbeleid de afnemers.

Het besturingscluster mesh-prd-<cel> is een gehost cluster met drie werkers, met istiod als externe besturing, meshID dc3 en een network per cel. Iedere cel heeft een eigen vertrouwensdomein, gelijk aan dat van de applicatie-identiteit, en een tussen-CA onder een gemeenschappelijke wortel; de besturingsclusters van de cellen zijn niet gekoppeld. Applicatieclusters sluiten aan als remote, met per cluster een east-west gateway. Via beleid komen de operator van OpenShift Service Mesh 3.4, op de applicatieclusters IstioCNI en ZTunnel (profiel ambient, elk met de naam default) en op teamnaamruimten het label istio.io/dataplane-mode=ambient. De clusterdefinitie zet OVN-Kubernetes op gatewayConfig.routingViaHost true. Certificaten komen via istio-csr van cert-manager met een Issuer op de PKI van OpenBao onder de tussen-CA van de cel. Per naamruimte weigert een AuthorizationPolicy standaard en staat zij toe op principal uit de dienstbeschrijving, in ontwikkelen en beproeven als dry run; een waypoint komt er alleen op aanvraag. Uitgaand verkeer loopt via een egress-gateway met een ServiceEntry per bestemming, naast de EgressFirewall. Netwerkbeleid voor de onderdelen van het dienstennetwerk staat aan, en Kiali is een console-plug-in met alleen-lezen rechten per team.

Na de ingebruikname volgt de update van het dienstennetwerk het ritme van de platformsoftware; de leverancier brengt ongeveer drie versies per jaar uit, zonder verlengde ondersteuning. De besturing wordt op het besturingscluster bijgewerkt en de gedeelde component ter plekke op iedere werker. Omdat die update het verkeer van alle toepassingen op de werker raakt, gaat zij eerst naar de proefgroep, waar de onderbreking van het verkeer wordt gemeten.