23 Oktober 2021

OKD Cluster bei Hetzner

Hetzner Rechenzentrum

OKD4 wird langsam beliebt. Wer kein Geld für einen vollwertigen OpenShift Cluster hat, hat hier eine Chance auf den Service. Für VMs auf Basis von oVirt gibt es auf GitHub einige Projekte, die Installationen durchführen. Wie man aber einen Cluster auf echten Maschinen bei Hetzner aufbaut, muss man sich zusammensuchen.

Ich habe bis for ein paar Tagen einen OKD 3.11 Cluster als Single-Node-Cluster auf einem Node laufen gehabt. 64GB Hauptspeicher, 16 Cores. Da ich sowieso auf OKD 4 wechseln wollte und die Leistung am Ende war, habe ich mir jetzt drei Server mit jeweils 12 Cores und 64 GB Hauptspeicher geholt. Platten sind jeweils 500 GB enthalten. Als Loadblancer habe ich mir auf der Serverbörse zwei kleine Maschinen geschossen, die jeweils per haproxy auf den Cluster loadblancen. Außerdem werde ich dort ein paar weitere Dienste installieren, die nicht in Kubernetes laufen oder ich nicht dort haben will.

Weiterlesen
12 Oktober 2020

Live-Coding auf Twitch und Youtube

Nachdem sich Let’s Plays und einfache Chat-Streams als erfolgreich gezeigt haben und auch technische Webinars fast zum Standard geworden sind, will ich das noch weiter treiben.

Ich werde meine Softwareentwicklung des Operators unter https://github.com/klenkes74/k8s-installed-feature-catalogue vollständig streamen. Die Streams werden bis auf weiteres auf Twitch laufen und dann später als Uploads auf Youtube hochgeladen.

Wenn ihr weitere Ideen habt oder euch beteiligen möchtet, bin ich natürlich immer offen.

7 April 2020

OpenShift or Kubernetes cluster configuration catalogue

Old Phonebook (lusi@rgbstock)

Kubernetes is not kubernetes. Every cluster is configured in a special way and offers additional features. Some of them are build in the distribution, like OpenShift contains for example a default ingress service (the router) – others are provided by the team maintaining the cluster. Or the maintaining team of the cluster decided not to provide certain features of k8s or the distribution used.

How do you communicate the feature set you provide to your customers. For a single cluster and a small group of users it’s easy: you explain it to your users. But the bigger the cluster grows and the more users you have, you find out: this does not scale. And adding multiple clusters in different versions, it becomes a mess.

But you could use a k8s feature to build a catalogue of features of the current cluster. You define the feature sets and add the installed features to the cluster and your users may query the cluster about the supported features of the cluster they want to use.

The k8s feature I’m talking about is the custom resource. Just create a custom resource containing the information you want to provide and add the features to the catalogue. Then the catalogue can be queried like this:

$ oc get ift
NAME                 GROUP          VERSION        AGE       DOCUMENTATION
features-catalogue   cluster-info   1.0.0-alpha1   1d        https://github.com/klenkes74/k8s-installed-features-catalogue/
$

I don’t want to double the information, so I point for the implementation to my github repo containing an implementation of this idea: https://github.com/klenkes74/k8s-installed-features-catalogue. Please comment and write your opinion of such a catalogue.

Titelbild: old phonebook (lusi@rgbstock, RGBStock Lizenz)

28 Mai 2019

Creating the s2i builder with ASCIIDOC generation software included

Vier aufgeschlagene Bücher auf einem Haufen

(Providing documentation the OpenShift way – Part 2)

For building the documentation pod, we need two components: the asciidoc html generator and the webserver for delivering the static pages later. There are several base containers published containing either the asciidoc generator or the webserver. I liked the converter published on https://github.com/asciidoctor/docker-asciidoctor. But that is only the generator part. On the other hand there are default bsic containers like httpd or nginx containing the web server part. Or, as third option you could use a ruby s2i builder as starting point and add both, Asciidoc and the web server later.

Weiterlesen
28 Mai 2019

Providing documentation the OpenShift way – Part 1

Vier aufgeschlagene Bücher auf einem Haufen

Documentation is one of the most hated part of the life of a developer. So the documentation is often the most neglected part of a project. At work I use Asciidoctor to write my customer documentation and it is quite acceptable. I loved LaTeX and Asciidoctor is an acceptable replacement for technical documentation – especially with the alternatives being google doc or word.

Weiterlesen