Welcome to this first article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

We have noticed that many of our customers struggle to understand how TLS certificates work on a conceptual level. For example, how does „signing“ work? What does it even mean? What are a „chain“, an „intermediate“ or a „root“? Why do intermediates belong to a chain, but not the root? What is a CSR? How do CSR, Key, and certificate work together? And so on.

This series is an attempt to explain these critical concepts to our customers, starting this first part with the basic vocabulary and knowledge to get started.

HTTPS – TLS – SSL

Let’s talk about what we want to achieve first. When you visit a website via plain old HTTP, an attacker could intercept your request and grab any private information like usernames and password. Additionally, there is no way for you to verify that you indeed connected to the server you intended. An attacker could have modified the DNS response (which is also unencrypted) to send your browser to their server instead. See Man-in-the-middle attack on Wikipedia for more examples.

So in order to verify the identity of the server we connected to, and to make sure nobody except the server and our browser can read the data we exchange, websites these days use TLS („Transport Layer Security“, or its predecessor SSL „Secure Sockets Layer“) to both authenticate the server and encrypt the traffic.

From a technical perspective, TLS sits between TCP and HTTP on the protocol stack, and while it’s mostly known for being the S (for Secure) part in HTTPS, it’s noteworthy that it can be used for other protocols as well. Some examples:

• Email protocols: IMAPS, POP3S, SMPTS, …​
• Database connections: MySQL, PostgreSQL, MongoDB, etcd, …​
• Data transfer: FTPS
• Telephony: SIPS
• Chat: XMPPS, IRCS, …​

The last thing to note here is that there are different versions of TLS (and SSL), and some of them are not considered secure anymore!

From oldest to newest, at the time of writing (March 2021):

• SSLv1: Insecure, not supported anymore
• SSLv2: Insecure, not supported anymore
• SSLv3: Insecure, not supported anymore
• TLS 1.0: Insecure, deprecated
• TLS 1.1: Insecure, deprecated
• TLS 1.2: OK
• TLS 1.3: OK

Keep this in mind when planning your environment! You wouldn’t want to protect your brand new microservice with outdated security protocols!

By the way, if you want to check which TLS versions a website supports, use SSL Labs‘ SSL Server Test. It’s a great debugging tool and will show you a lot of information about the topics of this Blog post series!

Certificates

The next thing we should have a look at are Certificates, or more specifically X.509 v3 public key certificates.

A Certificate is a cryptographically signed piece of information, of which the most important part is the Subject, which identifies who this certificate belongs to, as well as the Issuer. Other attributes include details about when the certificate is about to expire as well as a lot of technical information about the key and signature algorithms used, and so on.

The Subject and Issuer of a certificate are characterized by a set of attributes:

• CN – Common Name
• C – Country
• ST – State
• L – Location (City)
• O – Organisation
• OU – Organisational Unit

Together, those attributes form a Distinguished Name (DN). Most attributes are optional, except for the Common Name. In the case of Server Certificates, the CN must match the address used to connect, for example www.vshn.ch.

The Certificate also contains a Public Key (embedded in the certificate) and its matching Private Key.

The last important feature of X.509 certificates is that they are signed by other certificates (or itself). Once a certificate is signed, its contents cannot be changed anymore.

Signing CAs

The Internet is a big place, so how do we know whom to trust? To solve this issue, the concept of Certificate Authorities came up.

A Certificate Authority (commonly referred to as CA) is a central trusted source of certificates. They have a CA Certificate (also known as the „root“ certificate) that is well known and trusted. This certificate is only used to sign other certificates. By signing another certificate, the CA confirms „yes, I trust this certificate and the information in it is correct.“

A related concept is a Certificate revocation list, also known as „CRL“, which is a list of digital certificates that have been revoked by the CA before their scheduled expiration date, and should therefore no longer be trusted.

Now that we have explained what a certificate is, let’s talk about keys.

Keys

Each certificate has its own key. The key makes certificates actually useful; without them, they would not work.

Each key consists of two parts: a public key and a private key. While the public key is embedded as part of the certificate itself, the private key is stored in a different file altogether.

In order to sign another certificate, you need the Private key of the signing certificate (but not of the certificate you want to sign).

When you open a connection to a server, the server also needs the private key of the server certificate in order to authenticate itself and establish encrypted communication.

This whole concept is called Public-key cryptography.

Confidentiality

A very important thing to understand is that the key is the only confidential piece in the puzzle; needless to say, it is the most important piece! So please, keep this always in mind: do not ever exchange keys over unsecured channels, under any circumstances!

On the other hand, the certificate itself is not confidential. The CA certificate in particular must be provided to all clients and servers, in order to verify other certificates.

How can a client ask a CA to sign a certificate? Through a CSR (also known as Certificate Signing Request) which, as the name implies, performs exactly this task.

Coming Up

Speaking about verification and issuing new certificates, we are going to talk about these subjects in detail, respectively in the second and third parts of this series. Stay tuned!

I think it can be said that at VSHN we have a certain obsession with documentation. This goes beyond the requirements set by our customers, or by those imposed by certifications such as the ISO 27001 or ISAE-3402. We have found that as a team we can work better when we can refer to written documentation at all times.

In the past few years we have standardized our documentation toolkit: we have adopted Asciidoctor as the lingua franca for our documentation. We have put in production various documentation websites based on Antora: our Handbook, our Knowledge Base, and the Project Syn documentation are some examples.

That works great for text. But what about diagrams? Our documentation has lots of them, and although embedding PNG files works fine, it does not “scale” very well.

For that reason we have set up an instance of Kroki in production (in APPUiO, of course!), to enable the generation of SVG diagrams based on various formats: PlantUML for UML diagrams, Nwdiag for network diagrams, and Ditaa for simple box-and-arrow kind of diagrams, all produced and shown in a crisp and neat SVG format. We love Kroki! It is such an awesome idea, that it has even been integrated to GitLab as a supported diagramming tool. How cool is that? In general, the Asciidoctor ecosystem has very good integration of diagrams into workflows, and this extends to Antora as well.

I am not going to dive into the benefits of vector vs. raster images; I think the readers of this article are well aware of the bonuses the former has over the latter. SVG diagrams look great in both online and print, but they can be a bit complicated to draw by hand (duh!).

But here’s a confession: I’m not a big fan of editing text-based diagrams either. But that’s just a personal choice. And the truth is, many other non-technical VSHNeers find the whole “diagrams as text” thing a bit arcane.

So that means that we needed a more accessible tool for them. The ideal diagram drawing tool for VSHN must have the following requirements:

• Cross-platform: Most of us at VSHN use Linux, but a sizable number also use Macs and Windows laptops.
• Accessible to non-technical VSHNeers: Not everyone at VSHN is a DevOps engineer.
• Simple to use: If possible, using a point-and-click interface; for example, in our Confluence wiki we have enabled the Gliffy extension, which allows non-technical users to create stunning diagrams.

So we started our search. Leaving aside tools like Inkscape, that are too generic, like Asciiflow, that are too limited, or like Dia, that are too platform-specific, it took us a while to find a tool that would fit our requirements. But we found it!

Please welcome Diagrams.net (previously also known as Draw.io). It is a web application geared specifically to the generation of diagrams, very easy to use and ticking all the boxes that we needed.

And even better, there is a Visual Studio Code extension that allows to edit diagrams locally, directly on your laptop, in Linux, Mac and Windows.

How do we integrate this with Antora? Very simple. In the assets/images folder of our documentation components, create your diagrams using the *.drawio.svg extension. These are automatically associated by Visual Studio Code with the extension, and provides a live editor with all the bells and whistles you might expect.

And then, well, just image::diagram.drawio.svg[] in your documents, git commit and push.

This approach is definitely more accessible to non-technical VSHNeers, making it super easy to edit diagrams online, or locally in Visual Studio Code.

To finish, here’s a Pro Tip™®©: switch the Draw.io extension to the “Atlas” theme, since some lines in the extension lack contrast, and aren’t easily seen when using a dark theme. You can change the Draw.io extension theme with the selector at the bottom right of the screen.

PS: there is an open issue in Kroki to add support for Draw.io diagrams. Can’t wait to see it in action!

Docker Inc., das Unternehmen, welches hinter Docker Hub steht, hat vor kurzem eine Beschränkungen der Image-Pull-Rate für Benutzer von Docker Hub angekündigt. Diese Änderung betrifft alle Cloud Native Installationen, die so konfiguriert sind, dass sie Container Images verbrauchen, welche in Docker Hub gespeichert sind, einer der populärsten Container Registries. Diese Massnahme hat direkte Auswirkungen auf den Einsatz vieler Kundenanwendungen, die derzeit auf APPUiO Public und privaten Clustern laufen.

Wir verfolgen die Situation aufmerksam. Nach den jüngsten Ankündigungen beginnt der Docker Hub langsam damit, eine Begrenzung der Abrufrate auf 100 Abrufe pro 6 Stunden für anonyme (nicht authentifizierte) IP-Adressen und 200 Abrufe pro 6 Stunden für authentifizierte kostenlose Benutzer durchzusetzen. Dies bedeutet, dass ein gesamter Kubernetes- oder OpenShift-Cluster ohne authentifizierung für alle seine Benutzer nur 100 Container Images in 6 Stunden von Docker Hub abrufen kann. Während Wartungsperioden werden üblicherweise die meisten Container Images eines Clusters abgerufen. Eine Reduzierung der Limite für die Abrufrate kann aus diesem Grund zu Ausfallzeiten führen.

Diese Situation sollte das heutige Wartungsfenster nicht beeinträchtigen. Obwohl die Beschränkung der Abrufrate am Montag, dem 2. Oktober 2020 angekündigt wurde, zeigt eine Analyse der „Responses“ von Docker Hub, dass die neuen Begrenzungen noch nicht angewendet wurden. Diese werden nur während eines 3-Stunden-Fensters von 18:00 bis 21:00 Uhr (MEZ) morgen durchgesetzt . Leider wissen wir zu diesem Zeitpunkt noch nicht, wann die neuen Pull-Rate-Limits vollständig durchgesetzt werden.

Bemerkenswert ist auch, dass diese Einschränkungen weder für die interne OpenShift-Registry gelten die in APPUiO Public oder Private enthalten ist und die völlig unabhängig vom Docker Hub ist, noch für Docker-Benutzer mit Pro- oder Team-Konten. Authentifizierte Benutzer mit Pro- oder Team-Konten können unbegrenzt Daten von und zum Docker Hub übertragen.

VSHN evaluiert derzeit Massnahmen, um Ausfallzeiten zu verhindern und die Auswirkungen dieser Situation für unsere Kunden zu reduzieren. Die derzeit geeignetste Lösung besteht in der Umstellung auf die oben genannten Pro- oder Team-Docker-Kontoarten. Noch einfacher ist die Verwendung eines authentifizierten Benutzerkontos als Pull Secret anstelle eines anonymen Kontos, das die Pull-Rate-Grenze verdoppelt und das Risiko von Ausfallzeiten erheblich verringern könnte. Eine andere Möglichkeit besteht darin, Container Images in ein anderes öffentliches Register zu migrieren, wie z.B. Red Hat Quay. Eine andere Möglichkeit ist die Verwendung eines privaten Registers, wie AWS ECR, GitLab Container Registry, Harbor oder andere ähnliche Technologien. Insbesondere hat AWS kürzlich die zukünftige Verfügbarkeit („innerhalb von Wochen“) eines kostenlosen öffentlichen Registers angekündigt.

Bei Fragen dürfen Sie uns gerne kontaktieren.

This is about how we manage large numbers of ModSecurity WAF deployments, including CRS and custom rules.

ModSecurity CRS Berne Meetup

At VSHN we’re not only 100% committed to Free and Open Source software, we also collaborate actively with the communities of the software we use, deploy and enhance. This June, we had the pleasure to join the OWASP ModSecurity Core Rule Set Berne Meetup group online who had asked us back in November at yet another Meetup to showcase the way we use ModSecurity and the Core Rule Set (CRS).

This post comes late after my EuroPython 2019 talk on „Modern Continuous Delivery“ in Basel. But there is no need to worry: Advice on writing software that outlasts hypes on modern computing has no hurry to appear on stage.

What a great time!

Deployment automation, cloud platforms, containerization, short iterations to develop and release software—we’ve progressed a lot. And finally it’s official: Kubernetes and OpenShift are the established platforms to help us do scaling and zero downtime deployments with just a few hundred lines of YAML. It’s a great time.
Can we finally put all our eggs into one basket? Identify the cloud platform that fits our needs, and jump on it? That could well backfire: Vendor lock-in is the new waterfall, it slows you down. In future you’ll want to jump over to the next better platform, in a matter of minutes. Not months.
So, how do we do that? What’s the right approach?

The definition of Continuous Delivery

What does modern software development look like?

A modern software development project does:

1. Immutable infrastructure („containerization“)
2. Container orchestration (e.g. Kubernetes, Docker Swarm)
3. Version control and automation (CI/CD, „pipelines“)
4. Cloud-native applications (resilient apps that scale)

Nothing new. You’ve heard this before.

Vendor lock-in is the new waterfall

Software development has become complex. So complex that there are numerous services popping up almost daily that help us getting things done. Most notably, these are application delivery platforms nowadays (Amazon AWS, Microsoft Azure, Google Cloud — just to name a few). When we use offerings across several such providers, which is becoming increasingly popular, we speak of multi-cloud dependencies.

While all offerings are choices they typically entail a lock-in, because we don’t have standards and tooling yet that allow us to effortlessly switch from one solution provider to another. And when there are reasons to make a switch, lock-ins make it inherently difficult to move fast. This is a problem.

What can we do about vendor lock-in?

Software development is not about „using <technology>“ or „using <platform>“. As engineers we must think in terms of „problem to solve“ (requirements) and applying proper development practices (engineering). If we rely on platforms to solve problems for us we’re doing it wrong. Engineers must learn to follow principles of good software design, to write and maintain „clean code“.

One of those principles you learn as an engineer is to maintain boundaries between systems. In a modern software development project you’ll see four of such „layers of responsibility“ that define boundaries:

1. Application
2. Development
3. Deployment
4. Automation

Think in terms of technologies and tools, or services and environments you use in each to understand why we have those.

1. The application layer is like how you did software development 15 years ago. It’s just concerned with getting things running locally. Add the 12factor app methodology and you get an application that is prepared for potential target environments.
2. The development layer is concerned with supporting the development in the application layer. Developer tooling that gets the project running with a single command, a test infrastructure setup and QA tooling, which should also be easy to handle.
3. The deployment layer reuses that part of the development layer that made the developer deploy the application locally, for development. It also houses configuration files used only in productive target environments and deployment configuration that describes the entire productive setup.
4. The automation layer is only concerned about automating the steps you would otherwise perform manually to deploy your application.

Clean separation and interfaces

Now we have layers. What do we gain?
Note how the layers use an interface to talk to the next layer above. This allows us to address them separately. In other words,

• When you want to use a different CI service (e.g. switch from Bitbucket Pipelines to GitLab CI) you only refactor the implementation in the automation layer (i.e. the CI configuration).
• When you want to change your container orchestration (e.g. switch from OpenShift to Kubernetes) you only refactor your implementation of the deployment layer (e.g. use Kustomize instead of OpenShift templates and Ingress instead of Routes, etc.). You may also have to change some of the deployment tooling in the automation layer as a consequence (e.g. use kubectl instead of oc), but it’s all cleanly separated.

This is the power of separation of concerns.
Also note that for this to work well you need to make your interfaces simple and stable.

• For development use a task runner to turn your common tasks into single commands or simple one-liners (in JavaScript you may use gulp, in Ruby rake, in Python tox).
• Don’t design for target environments in your application layer! Design with features in mind and only combine them to environment configurations in your deployment layer.
• Stick to standard procedures and established tooling (instead of proprietary or self-invented solutions) for the technologies you use. This is typically more stable as an interface, will save collaborators from learning how to work with your setup and make it unnecessary to add extensive instructions to the README.

The more you invest in this flexibility and clean separation the easier your task will be when the day comes to make a change.

Working code samples to your rescue

What is better than starting to investigate late and working on refactoring under time pressure? Knowing your possibilities and turning to working code samples when you need them!
That’s where the Painless Continuous Delivery Cookiecutter comes into play. It’s a project template generator covering many of the most popular combinations of public service offerings you may be working with. At VSHN AG we’re working on extending it—for your independence. Try it out, let us know if you find it useful, and contribute if you feel like!
For the start you may want to take a look at one of the generated setups on GitLab, the live demo for the EuroPython talk. Enjoy!

EuroPython 2019: Modern Continuous Delivery for Python Developers

Slides of this talk are available from SpeakerDeck.
This article has originally been published on Peter’s personal website.

use create

deploye unsere Operatoren Schritt für Schritt.
Für diesen SDK-unterstützten Workflow bieten wir:

a) eine Beschreibung der generierten Operator-Struktur (es gibt eine für jeden spezifischen Workflow);

b) einen Link zu unseren Operator-Beispielen basierend auf einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.

c) Beschreibungen wie (z.B. 3rd-Party) Ressourcen, die sich vom Core Kubernetes Ressource-Typ unterscheiden, zum Operator hinzugefügt werden können

d) eine Beschreibung der wichtigsten Vor- und Nachteile der Verwendung einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.

a) Beschreibung der generierten Operator-Struktur (es gibt eine für jeden spezifischen Workflow)

Nachfolgend die Struktur eines generierten GO-Operators:

Operator scope

Ein namespace-scoped Operator (der Standard) überwacht und verwaltet Ressourcen in einem einzigen Namespace, während ein cluster-scoped Operator Ressourcen clusterweit überwacht und verwaltet. Namespace-scoped Operators werden wegen ihrer Flexibilität bevorzugt. Sie ermöglichen entkoppelte Upgrades, Namespace Isolation für Fehler und Überwachung sowie unterschiedliche API Definitionen. Es gibt jedoch Anwendungsfälle, in denen ein cluster-scoped Operator sinnvoll sein kann. So wird beispielsweise der cert-manager Operator häufig mit cluster-scoped Berechtigungen und Überwachungen eingesetzt, um die Ausstellung von Zertifikaten für einen ganzen Cluster zu verwalten.

b) Beispiele von Operator(en) basierend auf einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.

Wir diskutieren zwei Beispiele eines GO-Operators: 
1) Beispiel 1: Dieser Operator repliziert sich nur unter einem bestimmten Projekt
2) Beispiel 2: Dieser Operator erlaubt es, die Anzahl der Pods in einem Projekt zu manipulieren.

c) Wie 3rd Party Ressourcen (z.B. unterschiedlich zum Core Kubernetes Ressource-Typ) zum Operator hinzufügen

Der Operator-Manager unterstützt die Core Kubernetes Ressourcen-Typen, wie sie im client-go scheme („register.go„) Paket enthalten sind und registriert auch die Schemata aller benutzerdefinierten Ressourcen-Typen, die im Projekt definiert sind unter pkg/apis

Um eine 3rd Party Ressource zu einem Operator hinzuzufügen, musst du sie zum managers scheme hinzufügen. Indem du eine AddToScheme Methode erstellst oder wiederverwendest, kannst du ganz einfach eine Ressource zu deinem Schema hinzufügen. Ein Beispiel zeigt, dass du eine Funktion definierst und dann mit dem runtime Paket nutzt, um einen SchemeBuilder zu erstellen.
Registriere dich mit dem Managers Schema
Rufe die AddToScheme() Funktion auf für deine 3rd Party Ressource und übergebe sie in das Manager-Schema über mgr.GetScheme().
Beispiel:

„Nachdem du deinem Operator-Projekt neue Importpfade hinzugefügt hast, führe dep ensure im root-Verzeichnis deines Projektes aus, um die Abhängigkeiten zu erfüllen.“.

d) Eine Beschreibung der wichtigsten Vor- und Nachteile bei der Verwendung dieser Operatorstruktur (es gibt eine für jeden spezifischen Workflow) und Logik;

Vorteile (+) und Nachteile (-):

(+) Es ist einfach zu bedienen und erstellt einen einfachen Operator.

Das Hauptprogramm für den Operator cmd/manager/main.go initialisiert und führt den manager aus. Der Manager registriert automatisch das Schema für alle custom resource definiert unter pkg/apis/... und führt alle Controller aus unter pkg/controller/....

Der Manager kann den Namespace einschränken, den alle Controller auf Ressourcen überwachen:

mgr, err := manager.New(cfg, manager.Options{Namespace: namespace})

Standardmässig ist dies der Namespace, in dem der Operator läuft. Um alle Namespaces zu sehen, lassen Sie die Option namespace leer:

mgr, err := manager.New(cfg, manager.Options{Namespace: ""})

(+) genügend klare Möglichkeit, Ressourcen von 3rd Parties (d.h. anders als die Core Kubernetes Ressourcen-Typen) zum Operator hinzuzufügen.

(-) es ist immer noch instabil/Änderungen der APIs und die zukünftigen Versionen davon könnten nicht unterstützt werden (wir beobachten diese Entwicklung und aktualisieren den Blogbeitrag entsprechend).

Damit der Operator funktioniert, mussten wir einige Issues in Github öffnen (die geschlossen und als Fehler eingestuft wurden):

https://github.com/operator-framework/operator-sdk/issues/651

https://github.com/operator-framework/operator-sdk/issues/927

https://github.com/operator-framework/operator-sdk/issues/1053

(-) Der Workflow zur Erstellung der GO-Operatoren erscheint etwas komplexer/unklar (Schritte in rot) als der mit Ansible und Helm generierte (die weniger Schritte erfordern):

1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
2. Definiere neue Ressource-APIs durch Hinzufügen von Custom Resource Definitions (CRD)
3. Definiere Controller zur Überwachung und Abstimmung von Ressourcen
4. Schreibe die Abstimmungslogik für deinen Controller mit Hilfe des SDK und Controller-Runtime APIs
5. Verwende das SDK CLI Operator-Deployment-Manifest zum builden und generieren

Zurück zur Übersicht

Zurück zur Übersicht Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows.

2022–03–09: There’s a newer version of this article!

(This blog is currently only available in English and is the transcription of the presentation given at the CNC Switzerland meetup, May 9th 2019. Slides are available at the end of this page and impressions of the meetup can be found here.)

Serverless is one of those hot topics that, as many others in our industry, looks a bit like a good old idea recycled and brought back to fashion. Yet Serverless (or “Function as a Service”) looks like a natural evolution to a movement that started more than a decade ago, when Heroku and Google App Engine came under the spotlight.

As says Martin Fowler himself, Serverless and FaaS can be defined as follows:

FaaS is about running backend code without managing your own server systems or your own long-lived server applications.

At VSHN we have been interested in the subject for years now, and even worked in a FaaS project for a customer two years ago.

But now that Kubernetes and Knative are emerging as the true “Golden Standards” of hosted cloud operations, we see the emergence of FaaS solutions running directly on top of them. And developers have been fast creating lots of solutions that somehow appear to occupy the same space. How do they compare? Which one to choose?

To answer these questions, we are going to give a brief description of the following frameworks, outlining some of their characteristics and relative strengths:

1. OpenFaaS
2. Fn Project
3. Fission
4. OpenWhisk
5. Kubeless
6. TriggerMesh

The order of the frameworks is not trivial; they are roughly ordered following their “level of abstraction” on top of Docker and Kubernetes. For each of these projects, we are going to provide the following information:

1. Project details;
2. Three demos, all of them recorded with asciinema using minikube;
3. Available triggers;
4. Supported programming languages.

1. OpenFaaS

OpenFaaS is the project with the most stars (14’000) on Github of all those in this article. It is mostly written in Go, featuring around 100 contributors, and the latest available version at the time of this writing is 0.13.0 (April 4th, 2019).

It is an independent project, funded through donations (Patreon, OpenCollective, and PayPal.)

From a developer experience perspective, it is a project quite complex to setup and use. It is based on Docker, which means that functions are actually packaged as containers, to be pushed to a repository, and to be built using a local Docker installation in the developer workstation. OpenFaaS manages the Dockerfile for the developers automatically, though.

OpenFaas has a “template store” with several available programming languages. It also provides developers with a command-line utility, called faas-cli, itself talking to a REST API documented using Swagger. Finally, there is a Serverless Framework plugin for those who need it.

The following asciicast shows a very simple interaction with OpenFaas. First we create a Python function, which we customize a bit, and then we deploy and call it from the command line; both directly and also using curl:

OpenFaaS functions can be called through the following triggers:

• HTTP
• Event Connectors: Kafka, Amazon SNS, Minio, CloudEvents, IFTTT, Redis, RabbitMQ…

Finally, developers can use the following programming languages with OpenFaaS:

• C#, F# (.NET Core)
• Go
• JavaScript (Node.js)
• Java (JVM)
• PHP 7
• Python / Python 3
• Ruby

2. Fn Project

The Fn Project has been started and is currently funded by Oracle, who uses a fork to power its own Oracle Functions product.

Just like OpenFaaS, it is hosted in Github and written in Go. The project has around 4000 stars and 80 contributors, and the latest version at the time of this writing is 0.3.703 (May 6th, 2019).

From a technical point of view, Fn can use any Docker container as a function, and it can run anywhere: in public, private, and hybrid clouds.

Fn has two major concepts: – Functions (defined in YAML) – Applications: groups of functions, which can be deployed all at once.

For developers, it offers a command-line tool called fn and a Serverless Framework plugin.

Fn functions can be triggered with HTTP calls, and can be developed using the following languages:

• Go
• JavaScript (Node.js)
• Java (JVM)
• Python
• Ruby
• C# (community supported)

The Fn marketing material further states that it “supports all languages”.

3. Fission

Fission is an open source, Kubernetes-native Serverless Framework. It allows functions to be deployed and executed instantly, mapping them to HTTP requests.

Its Github project is mostly written in Go, features 4300 stars and around 80 contributors at the time of this writing. Its latest available version is 1.2.0 (May 3rd, 2019). It was started and is currently maintained by Platform9.

Fission does not need Dockerfiles or Docker registries; it is based on the notion of environments. Functions are injected into those environments, which are a pool of containers with language runtimes, where functions are loaded and launched on demand.

Fission keeps in memory a set of images containing the runtimes where the functions will be run, injecting them and running them immediately when invoked. In this sense, it is similar to how AWS Lambda works.

For developers, it features a command line tool (fission) and a Serverless Framework plugin. They do not need to have a local Docker environment to build their functions into.

The following asciicast shows the basic operations required to create, deploy and call a function:

Currently, Fission supports following types of triggers:

• HTTP
• Time
• Message Queue
• Kubernetes Watch

Only the following programming languages can be used to create functions in Fission; the project is quite young and the list will probably grow in the future:

• Go
• Python
• JavaScript (Node.js)
• Java (JVM)

In our tests, using minikube as a support, Fission appears easy to use, but at the same time very fragile (in spite of what its version number might suggest.) Removing and re-creating environments and functions led to many problems, and the project is too young to have more than 5 (unanswered) questions on Stack Overflow. In short, a promising but yet rather immature product.

4. OpenWhisk

OpenWhisk is the behemoth in the room. This open source project was created by IBM and is currently managed by the Apache Foundation. This project is the most “corporate” ones of those described in this blog post. It is written in Scala, it features around 4000 stars in Github and has around 150 contributors. The latest available version at the time of this writing is 0.9.0 (October 31st, 2018.)

This framework has the following features:

• Very “corporate” in design and functionality;
• Secure by default;
• Forked by Adobe and other big corporations;

For developers, it features a command-line tool (wsk) and a Serverless Framework plugin.

OpenWhisk functions can be triggered by the following mechanisms:

• Message Queues
• Databases
• Document Stores
• Website or Web Apps
• Service APIs
• IoT Frameworks…

OpenWhisk function can be created using the following programming languages:

• C#, F# (.NET Core)
• JavaScript (Node.js)
• Swift
• Java, Scala (JVM)
• Go
• Python
• PHP
• Ruby
• Ballerina
• Through Docker Actions: Rust, Haskell…

The installation on minikube was the most complex and difficult of all the frameworks considered in this document. The tools have changed a lot in the last two years and resources online might be outdated. But in spite of those factors, this framework stands out by the quantity, breadth, and depth of the documentation, as well as by the number of integration and supported languages.

5. Kubeless

Kubeless is a promising framework created and maintained by Bitnami. It is an open source project on Github written in Go, with around 4600 stars and 80 contributors. At the time of this writing, its latest version is 1.0.3 (March 14th, 2019.)

In our tests it was the one offering the best developer experience. Very simple to install and use, it offers a command-line tool (kubeless) that is very similar to the AWS Lambda CLI. This is no coincidence, as the whole aim of the project is to provide an experience very close to that of AWS Lambda, Azure Functions or Google Cloud Functions.

For DevOps teams, Kubeless provides Prometheus monitoring of functions calls and latency, and a Serverless Framework plugin.

The following asciicast shows the basic interaction to create, deploy, and test a function using Kubeless:

Kubeless functions can be triggered through the following mechanisms:

• HTTP
• Cronjob
• PubSub mechanisms
  • Kafka
  • NATS messaging
• Data stream events
  • AWS Kinesis

These functions can be developed using the following languages and runtimes:

• Go
• Python
• JavaScript (Node.js)
• Java (JVM)
• Ruby
• C#, F# (.NET Core)
• Ballerina
• Custom runtimes possible

All frameworks herewith considered, Kubeless offered the most flawless experience of all. The documentation was solid and easy to follow, and there are plenty of online resources to guide developers into building applications using this platform.

6. TriggerMesh

TriggerMesh is the newest entry in the world of FaaS, and it will represent a major shift in the way serverless applications are deployed and executed. Founded ex-Kubeless engineers, it builds upon Kubernetes & Knative, providing features yet unseen in the serverless arena.

TriggerMesh functions can be triggered through cross-cloud triggers from AWS to functions on Knative:

• Code Commit
• Cognito
• DynamoDB
• Kinesis
• S3
• SNS
• SQS
• …

TriggerMesh has announced the following programming languages as options:

• Go
• JavaScript (Node.js)
• Python
• Ruby

Together with VSHN, TriggerMesh released the TriggerMesh Operator for OpenShift 4.0. OKD 4.0 was recently announced by Red Hat to bring additional automation to Kubernetes applications. The operator allows OpenShift users to install the TriggerMesh management platform and benefit from its integration with Knative, to power serverless workloads across multiple clouds.. TriggerMesh also allows CI/CD of serverless functions, as well as access to multi-cloud event sources, like Azure and AWS.

Comparison

The following chart summarizes some of the ideas of this article, and has been adapted from the “Examining the FaaS on K8S Market” article on the Cisco Blog.

Popularity

The following tweet provides interesting information about the current state of the FaaS-on-Kubernetes market:

Conclusion

I hope this summary will be useful to you! Having tested all of these options, here at VSHN we will be focusing our efforts in the TriggerMesh platform, which will provide a much more solid developer experience and an unprecedented level of flexibility. We believe that this is the next generation of serverless platforms and we cannot wait to bring its power to our customers.

TriggerMesh will be launching their TriggerMesh Cloud service in the near future which will allow users to host serverless functions and consume events from many cloud sources.  To join the TriggerMesh Early Adopters program and get access for free serverless hosting for a limited time only please visit cloud.triggermesh.io.

Sources

The author used the following articles, documents, and books for inspiration and guidance:

Articles

• Examining the FaaS on K8S Market
• Knative or OpenFaas?
• IBM Embraces Knative to Drive Serverless Standardization
• OpenFaaS on OpenShift
• Serverless: who’s on call now?
• Serverless Computing / Functions as a Service mit Appuio und Snafu
• Getting started with OpenFaaS on minikube
• The evolution of serverless and FaaS: Knative brings change
• Knative, a FaaS anti-pattern?
• 15 Frameworks for Creating Serverless Apps

Projects

• FaaS on Kubernetes
• Fission Python Guestbook

Presentations

• Function-as-a-service on Kubernetes
• Best practices for serverless architectures

Books

• • Serveless Ops
  • Kubernetes for Serverless Applications
  • Guide to Serverless Technologies

People

• Michael Hausenblas

Slides

The slides of the presentation are available in (and can be downloaded from) SpeakerDeck.

Dieser Blogbeitrag ist Teil der Serie Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.
IN FRÜHEREN BLOG-POSTS HABEN WIR ÜBER DIE FOLGENDEN THEMEN GESPROCHEN:
Abschnitt 1 – Operatoren, Operatoren-Framework und Operatoren-SDK

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

Abschnitt 2 – Unterstützte Kubernetes Operatoren-SDK Workflows

• Hier werden die drei verfügbaren alternativen Workflows zur Generierung von Operatoren erläutert, die von den letzten Versionen der Operatoren-SDK APIs bereitgestellt werden.
• Wir besprechen auch Vor- und Nachteile der Nutzung der verschiedenen Operatoren-Workflows.

IN DIESEM BEITRAG SPRECHEN WIR ÜBER:
Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows

• Hier zeigen wir Beispiele für die drei verfügbaren alternativen Workflows zur Generierung von Operatoren, die von den Operatoren-SDK APIs bereitgestellt werden.
• Wir konzentrieren uns speziell auf Go-Operatoren, da sie unserer Meinung nach die stabileren verfügbaren APIs sind.

Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows

Wir werden folgendes anschauen:
1) Operator: Go-Operator
2) Operator: Ansible-Operator [in Kürze verfügbar]
3) Operator: Helm-Operator [in Kürze verfügbar]
 
Für jeden dieser SDK-unterstützten Workflows bieten wir:
a) eine Beschreibung der generierten Operator-Struktur (es gibt eine für jeden spezifischen Workflow);
b) einen Link zu unserem/unseren Beispiel(en) von Operator(en), die auf einer solchen Operator-Struktur basieren (es gibt eine für jeden spezifischen Workflow) und Logik.
c) Beschreibungen, wie man solche (3rd Party) Ressourcen hinzufügt, die sich von den Core-Kubernetes-Ressourcentypen unterscheiden, zu deinem Operator 
d) eine Beschreibung der wichtigsten Vor- und Nachteile der Verwendung einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.

Zurück zur Übersicht

Zurück zur Übersicht Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.

Dieser Blogbeitrag ist Teil der Serie Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.
IN FRÜHEREN BLOG-POSTS HABEN WIR ÜBER DIE FOLGENDEN THEMEN GESPROCHEN:
Abschnitt 1 – Operatoren, Operatoren-Framework und Operatoren-SDK

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

IN DIESEM BEITRAG SPRECHEN WIR ÜBER:
Abschnitt 2 – Unterstützte Kubernetes Operatoren-SDK Workflows

• Hier werden die drei verfügbaren alternativen Workflows zur Generierung von Operatoren erläutert, die von den letzten Versionen der Operatoren-SDK APIs bereitgestellt werden.
• Wir besprechen auch Vor- und Nachteile der Nutzung der verschiedenen Operatoren-Workflows.

Abschnitt 2 – Unterstützte Operatoren-SDK Workflows

Wie bereits erwähnt, ist das Operator SDK auf GitHub ein sehr aktives Projekt, mit über 10 Releases, die in weniger als einem Jahr produziert wurden. Dies bedeutet, dass das Operator-SDK ein Toolkit ist, das sich im Laufe der Zeit weiterentwickelt (z.B. ändert sich sein Code, seine Struktur und Logik). Insbesondere, wie auf der Github-Hauptseite des Operator-SDK berichtet, sind die Bibliotheken und Tools mit „Projektstatus: pre-alpha“ gekennzeichnet und damit „signifikante Änderungen an der API in den kommenden Releases erwartet werden“.
Das Projekt startete im April 2018 und wir begannen es ab September 2018 intensiv zu beobachten. Wir haben herausgefunden, dass das SDK drei verschiedene Workflows zur Verfügung stellt, um Operatoren basierend auf Go, Ansible, oder Helm zu entwickeln.
Diese Versionen des Operators SDK sind zwischen 2018 und 2019 entstanden. Konkret basierte die erste Version des Operators auf Go und erst ab Dezember 2018 wurde eine Version auf Ansible bereitgestellt.
Schliesslich wurde Anfang 2019 (im Januar) auch der Operator-Workflow auf Basis von Helm freigegeben.
Somit bietet das SDK einen Workflow zur Entwicklung von Operatoren auf Basis von Go, Ansible, oder Helm.
Der folgende Workflow gilt für einen neuen Go-Operator:

1. 1. 1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
      2. Definition neuer Ressourcen-APIs durch Hinzufügen von Custom Resource Definitions (CRD).
      3. Definition von Controllern zur Überwachung und Abstimmung von Ressourcen.
      4. Schreibe die Abstimmlogik für den Controller über das SDK und die Controller-Laufzeit-APIs.
      5. Verwende das SDK CLI, um die Operator Deployment Manifeste zu erstellen und zu generieren.

Der folgende Workflow gilt für einen neuen Ansible-Operator:

1. 1. 1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
      2. Schreibe die Abstimmungslogik für das Objekt mit Hilfe von Ansible Playbooks und Rollen.
      3. Verwende das SDK CLI, um die Operator Deployment Manifeste zu erstellen und zu generieren.
      4. Optional kannst du mit Hilfe des SDK CLI weitere CRD’s hinzufügen und die Schritte 2 und 3 wiederholen.

Der folgende Workflow gilt für einen neuen Helm-Operator:

1. 1. 1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
      2. Erstelle ein neues (oder füge ein bestehendes) Helm-Chart hinzu, das von der Abstimmungslogik des Operators verwendet wird.
      3. Verwende das SDK CLI, um die Operator Deployment Manifeste zu erstellen und zu generieren.
      4. Optional kannst du mit Hilfe des SDK CLI weitere CRD’s hinzufügen und die Schritte 2 und 3 wiederholen.

Richtlinien:
Command Line Interface: Um mehr über den SDK CLI zu erfahren, lese die SDK CLI Reference, oder führe operator-sdk [command] -h aus.
Eine Anleitung zu Reconcilers, Clients, und Interaktion  mit Ressourcen-Events, siehe Client API doc.
Wie aus der folgenden Abbildung ersichtlich, gibt es keinen grossen Unterschied zwischen den verschiedenen Operator-Workflows.
Der Workflow, der die höchste Reife erreicht hat und mehr Kontrolle über das Verhalten des Operator bietet, ist der auf Go basierende:

Nächster Artikel

Abschnitt 3 – Beispiele für unterstützte Operatoren-SDK Workflows

Zurück zur Übersicht

Zurück zur Übersicht Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.

Einführung in Kubernetes Operatoren, das Operatoren-Framework und Operatoren-SDK

Dieser Blogbeitrag ist Teil der Serie Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.
Abschnitt 1 – Kubernetes Operatoren, Operatoren-Framework und Operatoren-SDK:

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

Abschnitt 1 – Kubernetes Operatoren, Operatoren-Framework und Operatoren-SDK:

a) Operatoren sind Kubernetes-Applikationen.
Eine Kubernetes-Applikation ist eine Applikation, die sowohl auf Kubernetes bereitgestellt als auch über die Kubernetes-APIs und kubectl-Tools verwaltet wird. Um Kubernetes optimal nutzen zu können, benötigst du eine Reihe zusammenhängender APIs, die erweitert werden müssen, um deine Kubernetes-Applikationen, zu warten und zu verwalten. Man kann sich Operatoren als die „Runtime vorstellen, die diese Art von Applikation auf Kubernetes verwaltet“.
Somit ist ein Operator eine Methode zum Packaging, Deployen and Verwalten einer Kubernetes-Applikation. Konzeptionell nimmt ein Operator menschliches Betriebswissen auf und kodiert es in Software, die leichter verpackt und mit den Consumern geteilt werden kann. Wir können uns einen Operator als eine Erweiterung des Engineering-Teams des Softwareanbieters vorstellen, der über die Kubernetes-Umgebung wacht und seinen aktuellen Zustand nutzt, um Entscheidungen in Millisekunden zu treffen. Operatoren folgen einem [Reifegradmodell] von der Basis- bis zur spezifischen Logik für eine Anwendung.
Wir haben in den letzten Jahren gesehen, dass sich die Fähigkeiten der Operatoren in ihrer Komplexität unterscheiden, je nachdem, wie viel Intelligenz in die Implementierungslogik des Operators selbst eingebracht wurde. Wir haben auch erfahren, dass die Erstellung eines Operators typischerweise mit der Automatisierung der Installations- und Self-Service-Funktionen einer Anwendung beginnt und sich dann weiterentwickelt, um je nach Anwendungsfall eine komplexere Automatisierung zu übernehmen. Daher sind fortgeschrittene Operatoren heute so konzipiert, dass sie Upgrades nahtlos handhaben, automatisch auf Ausfälle reagieren und keine Shortcuts nehmen, wie das Überspringen eines Software-Backup-Prozesses, um Zeit zu sparen.
b) Operatoren-Framework
Operatoren sind Kubernetes-native Applikationen, die die Verwaltung komplexer stateful Applikationen auf Kubernetes erleichtern, aber das Schreiben solcher Operatoren kann aufgrund von Herausforderungen wie (i) der Verwendung von Low-Level-APIs und (ii) mangelnder Modularität, die zu Duplication, Inkonsistenzen und unerwartetem Verhalten führt, sehr schwierig sein.
Um diesem Problem zu begegnen, werden derzeit mehrere Tools (z.B. das Operatoren-Framework, Kooper, Metacontroller, etc.) als Ergebnis jahrelanger Arbeit und Erfahrung der Red Hat, Kubernetes und CoreOS Open-Source-Communities bei der Erstellung von Operatoren eingeführt. Insbesondere Red Hat und die Kubernetes Open-Source-Community teilten sich das Operator Framework – ein Open-Source-Toolkit, das entwickelt wurde, um Operatoren effektiver, automatisierter und skalierbarer zu verwalten.
Das Operatoren-Framework  ist ein Open-Source-Toolkit, das aus mehreren low-level APIs besteht. Wir glauben, dass das neue Operatoren-Framework den nächsten grossen Schritt für Kubernetes darstellt, indem es eine Basis führender Praktiken verwendet, um die Barriere für die Anwendungsentwicklung auf Kubernetes zu verringern. Das Projekt bietet ein Software Development Kit (SDK) und die Möglichkeit, App-Installationen und -Aktualisierungen mithilfe des Lifecycle-Management-Mechanismus zu verwalten, während Administratoren die Operatoren-Funktionen in jedem Kubernetes-Cluster nutzen können.
Das Operatoren-Framework beinhaltet:

• • Operatoren-SDK: Ermöglicht es Entwicklern, Operatoren auf der Grundlage ihrer Fachkenntnisse zu erstellen, ohne dass Kenntnisse über die Komplexität der Kubernetes-API erforderlich sind.
  • Operatoren-Lifecycle-Management: Überwacht die Installation, Aktualisierung und Verwaltung des Lebenszyklus aller Operatoren (und der damit verbundenen Dienste), die über einen Kubernetes-Cluster laufen. Einmal gebaut, müssen die Operatoren auf einem Kubernetes-Cluster deployed werden. Der Operator-Lifecycle-Manager ist die Backplane, die die Verwaltung von Operatoren auf einem Kubernetes-Cluster erleichtert. Damit können Administratoren steuern, welche Operatoren in welchen Namespaces verfügbar sind und wer mit laufenden Operatoren interagieren kann. Sie können auch den gesamten Lebenszyklus der Operatoren und ihrer Ressourcen verwalten, z.B. Aktualisierungen für einen Operator und seine Ressourcen auslösen.
  • Operatoren-Metering (folgt in den kommenden Monaten): Ermöglicht Nutzungsberichte für Operatoren, die spezielle Dienste bereitstellen. In einer zukünftigen Version wird das Operatoren-Framework auch die Möglichkeit beinhalten, die Anwendungsnutzung zu messen – ein Kubernetes first, das Erweiterungen für zentrale IT-Teams zum Budgetieren und für Softwareanbieter, die kommerzielle Software anbieten, bietet. Operatoren-Metering wurde entwickelt, um in die CPU- und Speicherberichte des Clusters eingebunden zu werden, IaaS-Kosten zu berechnen und kundenspezifische Kennzahlen wie Lizenzierung zu berechnen.

Einfache, stateless Applikationen können die Lifecycle-Management-Funktionen des Operatoren-Frameworks nutzen ohne Code zu schreiben, indem sie einen generischen Operator (z.B. den Helm Operator) verwenden. Komplexe und stateful Applikationen sind jedoch der Ort, an dem ein Operator glänzen kann. Die cloud-ähnlichen Funktionen, die in den Operator-Code kodiert sind, können eine erweiterte Benutzererfahrung bieten und Funktionen wie Updates, Backups und Skalierung automatisieren.
Im nächsten Unterabschnitt diskutieren wir über das Operatoren-SDK, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.
c) Popularität des Operatoren-SDK
Das Operatoren-SDK ist ein Toolkit, das kürzlich auf dem Operatoren-Framework aufgebaut wurde und die Werkzeuge zum Erstellen, Testen und Verpacken von Operatoren bereitstellt. Zunächst erleichterte das SDK die Verbindung der Businesslogik einer Anwendung (z.B. wie man skaliert, aktualisiert oder sichert) mit der Kubernetes-API, um diese Operationen auszuführen. Im Laufe der Zeit entwickelt sich das SDK jedoch weiter, so dass Entwickler Anwendungen intelligenter gestalten und die Benutzerfreundlichkeit von Cloud Services nutzen können. Infolgedessen sind führende Praktiken und Codemuster, die von allen Operatoren gemeinsam genutzt werden im SDK enthalten, um zu verhindern, dass das Rad neu erfunden wird.
Aus Entwicklersicht ist der Einstiegspunkt das Operatoren-SDK, das von CoreOS stammt und als Teil des Operatoren-Frameworks angeboten wird und nach seiner Selbstbeschreibung „ein Open-Source-Toolkit ist, um Kubernetes native Anwendungen, sogenannte Operatoren, effektiv, automatisiert und skalierbar zu verwalten“. Das SDK richtet sich spezifisch an Go-Entwickler und Applikationen und selbst wenn derzeit die Unterstützung für andere Programmiersprachen (z.B. Java, C, etc.) fehlt, gibt es bereits Zukunftspläne für deren Integration.
In GitHub wird das Operatoren-SDK zu einem sehr aktiven Projekt, das bereits eine hohe Sichtbarkeit/Popularität erlangt hat:

• • über 200 Entwickler, die ihre Entwicklungen in GitHub geforkt haben, die meisten von ihnen spielen/erweitern einige einfache Beispiele von Operatoren;
  • ca. 1000 commits seit dem ersten Release (5. April 2018).
  • über 10 Releases die in weniger als einem Jahr produziert wurden.
  • eine zunehmende Anzahl von GitHub Issues, die in den letzten Monaten von anderen Mitwirkenden geöffnet wurden.
    • [einige wurden auch von uns geöffnet, siehe https://github.com/operator-framework/operator-sdk/issues/651 und https://github.com/operator-framework/operator-sdk/issues/927]
  • mit über 1200 Sternen ist es eines der beliebtesten/trending Go-Projekten auf Github https://github.com/trending/go?since=monthly

Selbst wenn das Projekt mit der Zeit immer beliebter wird, ist sein Projektstatus immer noch „pre-alpha“, was bedeutet, dass „signifikante Änderungen an der API in den kommenden Versionen erwartet werden„.
Daher erfordert das Operatoren-SDK Toolkit noch ein wenig mehr Reife, um in breiteren praktischen Arbeitsszenarien eingesetzt zu werden. Als Forscher glauben wir, dass dieses Software Development Kit (SDK) in Zukunft weit verbreitet sein wird, da es die Entwickler bei der Verwaltung von App-Installationen und -Updates mit Hilfe des Lifecycle-Management-Mechanismus unterstützen wird, während es Administratoren ermöglicht, die Operator-Fähigkeiten auf jedem Kubernetes-Cluster auszuüben (siehe folgende Abbildung, die die Gesamtansicht der geplanten Unterstützung des Operator-SDKs verdeutlicht).

Im Folgenden sprechen wir über den allgemeinen Workflow des Operatoren-SDK.
d) Allgemeiner Workflow von Operatoren-SDK
Das Operatoren-SDK  ist ein Toolkit, das die Werkzeuge zum Erstellen, Testen und Verpacken von Operatoren bereitstellt, wie in der folgenden Abbildung dargestellt.

Insbesondere stellt das Toolkit den folgenden spezifischen Workflow zur Verfügung, um das Schreiben, Erstellen, Testen und Paketieren eines neuen Go-Operators zu unterstützen:

1. 1. 1. Erstelle ein neues Operatoren-Projekt mit Hilfe des SDK Command Line Interface (CLI)
      2. Definition neuer Ressourcen-APIs durch Hinzufügen von Custom Resource Definitions (CRD)
      3. Definition von Controllern zur Überwachung und Abstimmung von Ressourcen
      4. Schreibe die Abstimmlogik für deinen Controller mit dem SDK und der Controller-Laufzeit-APIs
      5. Verwende das SDK CLI um die Operatoren-Deployment-Manifeste zu erstellen und zu generieren

In diesem Zusammenhang verwendet das Operator-SDK für seinen Workflow die controller-runtime library, die das Schreiben von Operatoren erleichtert durch Bereitstellung von:

• • • High level APIs und Abstraktionen, um die operationale Logik intuitiver zu schreiben.
    • Tools für Scaffolding und Codegenerierung, um ein neues Projekt zu bootstrappen.
    • Erweiterungen zur Abdeckung gängiger Anwendungsfälle von Operatoren.

Ein einfaches Beispiel für die Erstellung und Bereitstellung eines einfachen Operators mit dem SDK-Toolkit findest du im offiziellen Operatoren-SDK GitHub-Repository:
https://github.com/operator-framework/operator-sdk
Der daraus resultierende automatisch generierte GO-Operator stellt die folgende Referenzstruktur dar:

Im nächsten Blogbeitrag werden wir über den aktuellen Status des Operatoren-SDKs sprechen, z.B. verfügbare Versionen und Workflows.

Nächster Artikel

Abschnitt 2 – Unterstützte Operatoren-SDK Workflows

Zurück zur Übersicht

Zurück zur Übersicht Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.

Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln

Kubernetes hat sich zu einer omnipräsenten Plattform für das Hosting von Cloud-native Applikationen entwickelt. Als eher Low-Level-Plattform wird sie oft entwicklerfreundlich gemacht, indem sie in übergeordnete Plattformen wie OpenShift (OKD) verpackt und in eine Managed Service Plattform wie APPUiO umgewandelt wird, die in jede Cloud-Infrastruktur deployed werden kann. Applikationsentwickler interagieren mit Kubernetes hauptsächlich, indem sie geeignete Deployment-Deskriptoren erstellen und ihren Code, der die Deployments auslöst, forcieren. Aufgrund ständiger Funktionserweiterungen ist nicht so viel über nützliche Kombinationen von Annotationen auf Kubernetes-Deployments (und anderen deklarativ beschriebenen Objekten), Kubernetes-Operatoren (eine Art von Hooks) und Custom Resource Definitions bekannt
In dieser Beitragsserie teilen wir einige der Erfahrungen, die wir bei der Erforschung von Massnahmen zur Auslösung von Aktionen bei bestimmten Updates der Deskriptoren gesammelt haben, als Vorläufer dynamischer und autonomer Feedback-Loops, die die Deployments von Applikationen selbst verwalten können.
Insbesondere bieten wir Zugang zu den angepassten Originalbeispielen von Operatoren, die mit dem Operator SDK-Toolkit generiert wurden, die sich mit Kubernetes-Ressourcen befassen, indem sie Annotationen zu Kubernetes-Deployments und Kubernetes-Operator Konzepten kombinieren. Der Link zu unseren Operator Beispielen ist auf Github verfügbar: https://github.com/appuio/operator-sdk-examples. In weiteren Blog-Posts werden wir einige beschreiben und diskutieren, wie sie für eine fortgeschrittenere Entscheidungsfindung erweitert werden können. Insbesondere die Anpassung der (Go)-Operatoren, damit sie in verschiedenen Umgebungen funktionieren, erfordert die Änderung einiger wichtiger Go-Dateien (z.B. pkg/controller/memcached/memcached/memcached_controller.go wie in der folgenden Abbildung dargestellt).

IN WEITEREN BLOG-POSTS SPRECHEN WIR ÜBER

Abschnitt 1 – Kubernetes Operatoren, Operatoren-Framework und Operatoren-SDK

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

Abschnitt 2 – Unterstützte Kubernetes Operatoren-SDK Workflows

• Hier werden die drei verfügbaren alternativen Workflows zur Generierung von Operatoren erläutert, die von den letzten Versionen der Operatoren-SDK APIs bereitgestellt werden.
• Wir besprechen auch Vor- und Nachteile der Nutzung der verschiedenen Operatoren-Workflows.

Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows

• Hier zeigen wir Beispiele für die drei verfügbaren alternativen Workflows zur Generierung von Operatoren, die von den Operatoren-SDK APIs bereitgestellt werden.
• Wir konzentrieren uns speziell auf Go-Operatoren, da sie unserer Meinung nach die stabileren verfügbaren APIs sind.

Abschnitt 4 – Beispiel(e) von Operatoren, die Dienste mit Prometheus monitoren (in Kürze verfügbar)

• Hier zeigen wir ein Beispiel für einen Operator, der mit Prometheus (derzeit zur Überwachung von Kubernetes-Clustern eingesetzt) kommuniziert, um fortgeschrittenere Entscheidungen zu treffen (z.B. erweiterte Überwachung des Dienstes).

Über die Autoren

Diese Beitragsserie wurde von Dr. Josef Spillner und Dr. Sebastiano Panichella von der ZHAW (Zürcher Hochschule für Angewandte Wissenschaften) School of Engineering geschrieben. Vielen Dank an Josef und Sebastiano, dass sie ihr Wissen mit unseren Lesern teilen!