Uitgelichte Features; OpenShift, Cloud Foundry, Rancher en Kubernetes

Dit is het derde artikel in een reeks van drie over een aantal moderne verschijningsvarianten van containerplatformen. In het eerste artikel heb ik een inleiding gegeven op deze platformen door middel van een algemene beschrijving van functionaliteit en de ontwikkeling die ze de afgelopen jaren hebben doorgemaakt. In het tweede artikel ben ik meer de diepte ingegaan en heb ik de architectuur en de verschillende varianten die beschikbaar zijn beschreven. In dit laatste artikel beschrijf ik een 28-tal inhoudelijke functionaliteiten.

Overzicht features containerplatformen

Uitgelichte features

Nummer 8: Supported Kubernetes version

Waar Pivotal en Red Hat aanvankelijk een relatief voorzichtige benadering hadden van welke versie van Kubernetes werd geïmplementeerd in hun platformen, bieden ze nu net als Rancher ondersteuning voor de huidige versie van Kubernetes, namelijk 1.20.

Nummer 9: Available since

De eerste stabiele versie van Kubernetes is van 2014. Red Hat was de snelste met het aankondigen van ondersteuning (ook in 2014, zie dit blogartikel), terwijl Rancher (die een eigen orkestratie technologie genaamd Cattle aanbood) in 2016 volgde (zie dit blogartikel). Pivotal kondigde ondersteuning voor Kubernetes in 2019 aan, voor het product PAS.

Zowel OpenShift als Pivotal PAS zijn al sinds 2011 beschikbaar, in verschillende versies. Ondersteuning voor containers was vanaf het allereerste begin beschikbaar (via Docker of een eigen container engine). De platformen hebben zich vervolgens meer richting containerorkestratie via Kubernetes geëvolueerd.

Nummer 10: (Image) repository

Een containerplatform heeft een plaats nodig om platform-gerelateerd materiaal op te slaan, zoals configuraties, containerimages en binaire bestanden. Onlangs introduceerde Weaveworks de term GitOps, die als volgt wordt uitgelegd: “GitOps is a way to do Kubernetes cluster management and application delivery.  It works by using Git as a single source of truth for declarative infrastructure and applications.” (https://www.weave.works/technologies/gitops/). De verschillende platformaanbieders omarmen GitOps echter (nog?) niet volledig. Pivotal maakt gebruik van het open source tool Harbor van VMWare, terwijl Red Hat momenteel een eigen, ingebouwd register gebruikt. Met de overname van CoreOS beschikt het bedrijf nu ook over Quay, sinds kort ook open source (zie dit artikel), dat beschikbaar is als gehoste service of (privé) cloud-installatie. Rancher heeft geen specifieke voorkeur voor een image repository.

Nummer 11: Service registry and discovery

Wanneer een (micro)service wordt gedeployed in een container, is het nodig deze ergens te registreren zodat de service discoverable wordt. De meeste platformen gebruiken hier op dit moment Kubernetes DNS voor, behalve Pivotal PAS (die een eigen oplossing heeft). De introductie van services meshes zoals mogelijk gemaakt door Istio, gereed voor productie sinds juli 2018), vindt slechts mondjesmaat plaats. Rancher heeft Istio met ingang van v2.3.0 aangekondigd en Red Hat heeft inmiddels de OpenShift Service Mesh (die uit niet alleen Istio bestaat, maar ook Jaeger voor distributed tracing en Kiali voor visualisatie) geïntroduceerd. Pivotal heeft ondersteuning voor Istio in PAS 2.5 aangekondigd (zie dit artikel).

Nummer 12: Messaging

Alhoewel de configuratie van Kafka op Kubernetes lastig kan zijn (bijvoorbeeld omdat Kafka een stateful systeem is – zie bijvoorbeeld https://www.confluent.io/blog/apache-kafka-kubernetes-could-you-should-you/), biedt elk platform behalve Pivotal PAS (dat NATS gebruikt) een vorm van ondersteuning voor Kafka, via Confluent of AMQ Streams. Kubernetes zelf heeft geen voorkeur voor een messaging standaard, alhoewel er verschillende AMQP-gebaseerde implementaties zijn (zoals RabbitMQ). Er is ook een NATS implementatie voor Kubernetes (https://github.com/nats-io/nats-operator).

Nummer 13: Load balancing and ingress

De platformen verschillen in hun implementaties van load balancing en ingress. Dit wordt waarschijnlijk veroorzaakt door het feit dat er buiten de standaard Kubernetes NGiNX variant geen referentie-implementatie is. Pivotal PAS en OpenShift gebruiken nog steeds hun eigen oplossing die stamt uit de tijd voor Kubernetes, namelijk HAProxy (OpenShift) en GoRouter (Pivotal PAS). Rancher gebruikt de NGiNX implementatie van Kubernetes.

Nummer 14: GUI

Alle platformen bieden een uitgebreide grafische interface, een behoorlijk verschil met een jaar geleden. In alle platformen is de Kubernetes GUI beschikbaar naast een vendor-specifieke GUI, behalve in Pivotal PKS (die alleen het Kubernetes dashboard biedt).

Nummer 15: Authentication

Het registreren, beheren van gebruikers en daaraan gekoppelde toegangsbeheer van deze gebruikers tot de platformen is door alle vendoren verschillend geïmplementeerd. Rancher heeft geen voorkeursimplementatie (de website beschrijft alleen connecties met third party producten). Pivotal heeft een eigen oplossing (CredHub en UAAC), terwijl Red Hat gebruik maakt van open source oplossingen die zijn gebaseerd op standaarden zoals OAuth.

Nummer 16: Function-as-a-Service (FAAS)

De mogelijkheid om functies op een platform te draaien (FAAS of Serverless) zonder je over de onderliggende infrastructuur te bekommeren werd in de zomer van 2018 opeens een stuk eenvoudiger met de introductie van KNative door Google. Alle vendoren bieden een variant van KNative in hun platformen (soms in beta). De impact die serverless op de onderliggende platformen gaat hebben is echter nog onzeker. Ik denk dat serverless zich beter leent voor public dan private cloud, maar dat zal het komende jaar uitwijzen.

Nummer 17: Logging (and monitoring)

Behalve Pivotal PAS (dat een eigen oplossing heeft voor zowel logging als monitoring) is de basis voor monitoring en metrics bij alle platformen gebaseerd op Prometheus (met Grafana voor dashboards). Voor logging lijkt Fluent (bit) de meest gebruikte keuze. OpenShift heeft een eigen, geïntegreerde oplossing met ElasticSearch, FluentD and Kibana (EFK), terwijl Rancher geen voorkeur voor een logging-tool heeft. In Pivotal PKS is alleen de collector (in de vorm van Fluent Bit) voorgeschreven.

Nummer 18: Storage system

In een platform dat is gebaseerd op Kubernetes wordt opslag standaard geïmplementeerd via het concept van Kubernetes PV (Persistent Volumes). In de Kubernetes documentatie staat hierover het volgende: “A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.” (zie ook dit artikel). Alle vendoren ondersteunen uiteraard PV, maar sommigen van hen hebben daarnaast een eigen, specifiek opslagsysteem beschikbaar: Red Hat biedt OpenShift Container Storage, een op Gluster gebaseerd systeem, terwijl Rancher met Longhorn een eigen Open Source storage platform heeft.

Nummer 19: Storage options

Alle platformen bieden een verscheidenheid aan opslagmogelijkheden, met een paar interessante aandachtspunten: Pivotal PAS ondersteunt S3, maar PKS niet (tenminste niet standaard: er zijn wel verschillende plugins beschikbaar, zoals bijvoorbeeld Minio en Altoros). Rancher beschrijft in de documentatie alleen voorbeelden met EBS en iSCSI, maar verwijst naar de Kubernetes-documentatie rondom opslag en beschikt over een catalogus met plugins voor opslag. De documentatie van Kubernetes bevat een lijst met alle ondersteunde opties (bestaande uit 28 volume types), een behoorlijk indrukwekkend overzicht.

Nummer 20: Application server

Pivotal PAS is van origine een “echte” PaaS (of applicatieserver, afhankelijk van hoe je het bekijkt) en ondersteunt Spring Boot als standaard. De andere vendoren hebben geen specifieke voorkeur: het is aan de gebruiker of ontwikkelaar om een applicatieserver te kiezen. Veelgebruikte varianten zijn opgenomen in de respectievelijke catalogi.

Nummer 21: Cache

Zowel Red Hat als Pivotal bieden een eigen Cloud Cache, namelijk Pivotal Cloud Cache en Red Hat Data Grid. Beide producten zijn relatief gelijkwaardig (in de zin dat het op Java-gebaseerde in-memory key-value datastores zijn), ook al zijn ze op verschillende onderliggende technologieën gebouwd. Pivotal Cloud Cache is gebaseerd op Apache Geode, terwijl Red Hat Data Grid een product in de JBoss suite is, gebaseerd op Infinispan.

Nummer 22: Database SQL and NoSQL

Ook hier is de oorsprong van Pivotal PAS als PaaS duidelijk zichtbaar. Het platform ondersteunt en biedt standaard MySQL. De andere vendoren hebben geen voorkeur en ondersteunen een groot aantal SQL en NoSQL-databases.

Nummer 23: Marketplace

Alle vendoren (behalve Kubernetes, maar uiteindelijk is dat ook geen vendor) bieden een marktplaats, waar het mogelijk is om voorgedefinieerde bouwstenen te selecteren en installeren. Red Hat is op dit moment de enige vendor die Kubernetes operators ondersteunt (zie ook dit artikel), maar Pivotal gaat ondersteuning toevoegen. Rancher biedt een catalogus gebaseerd op Helm charts. Helm en Operators zijn twee niet geheel gelijke manieren om applicaties richting Kubernetes clusters te deployen (of beter gezegd, een gestandaardiseerde manier om applicaties te beschrijven). Het is overigens ook mogelijk om operators te maken op basis van Helm charts, zoals beschreven door Red Hat.

Nummer 24: Auto update & upgrade

Met auto update bedoel ik het geautomatiseerd updaten of upgraden van het platform met zo min mogelijk impact (op performance) als mogelijk. Er zijn twee manieren om een Kubernetes cluster te upgraden: handmatig of automatisch. En automatisch kan vervolgens weer op twee manieren: zoals toegepast door Public Cloud of managed service providers (met eigen, specifiek voor hun Cloud ontwikkelde tooling), en de methode die door CoreOS wordt toegepast.

Met de overname van CoreOS, heeft Red Hat toegang gekregen tot de “over the air” update functionaliteit van Tectonic, die is geïntegreerd in de 4.x version van OpenShift (zie dit artikel). Dit betekent dat het mogelijk is om OpenShift automatisch te updaten / upgraden.

De handmatige Kubernetes upgrade procedure wordt door Rancher en Pivotal PKS gevolgd. Dergelijke upgrades zijn niet triviaal en het volgen van de Kubernetes drumbeat (een release per kwartaal) is eigenlijk verplicht, omdat het niet mogelijk is een point-to-point upgrade over te slaan: “You only can upgrade from one MINOR version to the next MINOR version, or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade. For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.” (zie dit document).

Nummer 25: Application deploy

Behalve Pivotal PAS (dat immers niet op Kubernetes is gebaseerd) gebruiken alle vendoren Kubectl om applicaties te (push) deployen op Kubernetes. Red Hat biedt in OpenShift ook een pull mechanism via het eigen Source2Image systeem. Een ander interessant product van Red Hat is Odo, een applicatie push tool specifiek bedoeld voor ontwikkelaars (zie ook dit artikel).

Nummer 26: Build mechanism

Pivotal heeft een eigen build mechanisme ontwikkeld, dat in zowel PKS als PAS wordt gebruikt. Het mechanisme is gebaseerd op Buildpacks van Heroku.

Rancher gebruikt Docker als container runtime. Er is echter een tendens om weg te bewegen (of tenminste meer alternatieven te bieden) van de focus op Docker als de standaard container runtime in Kubernetes. OpenShift is recent overgestapt op CRI-O en Kubernetes ondersteunt verschillende engines (zie ook onder 2 Containers). Wisselen naar een andere container engine dan Docker betekent dat ook het build mechanisme verandert, maar daarmee wordt het ook mogelijk om bouwen en runnen van containers te splitsen. Dit kan via de Google-tool Kaniko en Buildah van Red Hat. Met Kaniko is het bijvoorbeeld mogelijk een container image vanuit een container op te bouwen. Hierdoor is er geen container-build-omgeving meer nodig naast het containercluster.

Nummer 27: Command line

Elke vendor biedt een eigen set aan command line tools, naast de tooling die door Kubernetes wordt geboden (zoals Kubectl). Sommige tools zijn een uitbreiding op Kubectl, andere bieden specifieke functionaliteit (zoals de tooling van Pivotal).

Nummer 28: Pipeline

De manier waarop pipelines (CI/CD processen en toolsets) werken is niet in scope van dit artikel. Elk platform biedt echter een (minimale) pipeline die door DevOps team is te gebruiken. In de producten van Pivotal is dat Concourse. Rancher biedt Jenkins en dat was tot voor kort ook de keuze binnen OpenShift… maar Red Hat is recent geswitcht naar het eigen product OpenShift Pipelines, dat is gebaseerd op Tekton.

Tot slot

Deze blogserie is tot stand gekomen na veel research en gesprekken met productleveranciers. Fouten zitten er waarschijnlijk wel in, want vergissen is menselijk (en niet opzettelijk). En terwijl ik de vergelijking aan het maken was, verschenen alweer nieuwe, innovatievere versies van de platformen.

De stap van private PaaS naar public PaaS – dus het containerplatform volledig gehost in de public Cloud – is gemaakt en opent veel nieuwe mogelijkheden, vooral om de complexiteit van het beheer van een containerplatform aan externe partijen over te laten. En hoe dat werkt, daar verschijnt binnenkort vast een nieuw artikel over!