Möchte man ein privates Repository von GitHub auschecken, so kann man Zugriff auf das Repository über ein PAT (Personal Access Token) erhalten.
Dazu muss folgendes Schema angewendet werden:
git clone https://xxxxzzzzxxxxzzzzxxxxzzzzxxxxzzzzxxxxzz:@github.com/MaxMeier/Projekt.git
Wichtig ist der :, da dieser ein leeres Passwort signalisiert, welches bei einem PAT nicht benötigt wird.
Im Ersten Teil ( KeyClaok mit WebAuth ) haben wir das Setup für den K3S Cluster vorgenommen und KeyCloak darin deployt.
In diesem Zweiten Teil soll nun unsere Beispielanwendung in den Cluster deployt werden. Hierzu werden wir Gitea per Helm Chart installieren. Die Grundlage dafür kann unter https://chartcenter.io/k8s-land/gitea nachgelesen werden.
Für das Helm Chart müssen wir ein Repository für Gitea hinzufügen. Ich verwende in diesem Beispiel das von k8s-land.
helm repo add k8s-land https://charts.k8s.land
Die Values extrahieren und Einstellungen anpassen. Dazu laden wir sie mit dem helm show values Kommando herunter und speichern sie in der Datei values.yaml ab.
helm show values k8s-land/gitea > values.yaml
Die values.yaml werden wir im nächsten Abschnitt anpassen, damit die Anwendung nach unseren Gegebenheiten ordnungsgemäß funktioniert.
Damit das Chart mit dem Beispiel funktioniert, müssen in der values.yaml Datei einige Änderungen für den Ingress-Controller vorgenommen werden.
Wir wollen den Cert-Manager verwenden, um TLS für Gitea bereitzustellen. D.h. der Ingress-Controller lauscht auf Port 443, welcher beim Setup von K3d auf Port 8443 gemappt worden ist.
certManager: true
TLS muss für den Host gitea.cluster.local konfiguriert werden. Wir verwenden das Zertifikat first-tls aus dem ersten Teil der Artikelserie wieder.
tls:
- hosts:
- gitea.cluster.local
secretName: first-tls
Der ServiceType muss auf LoadBalancer umgeändert werden.
serviceType: LoadBalancer
Damit Gitea die korrekten URL und Port setzt, müssen wir es über die Parameter externalHost und externalPort propagieren.
externalPort: 8443
externalHost: gitea.cluster.local
Es ist für dieses Beispiel nicht direkt nötig, aber wir setzen hier ein statisches Passwort für den User gitea.
password: gitea
password: root
Für das Deployment wird ein eigener Namespace gitea verwendet.
helm install gitea k8s-land/gitea -f values.yaml -n gitea --create-namespace
Diesen geben wir mit dem Parameter -n gitea mit an und dieser wird wegen dem Parameter –create-namespace bei der Installation gleich automatisch angelegt.
Wenn der Service bereitsteht, dann sollte sich Gitea unter https://gitea.cluster.local:8443/ öffnen lassen.
helm uninstall -n gitea gitea
k delete namespace gitea
Ziel dieser Reihe soll es werden Anwendungen über WebAuthn zu schützen. Dazu wird ein K3S Cluster mit K3D aufgesetzt. Diese soll über .cluster.local erreichbar sein.
Im Ersten Teil beschäftige ich mich mit der Installation einer KeyCloak Instanz in einem K3S Cluster.
Im zweiten Teil wird die Demoanwendung (Gitea) deployt
Im dritte Teil geht es um die Konfiguration von KeyCloak, sodass die Anwendung von WebAuthn gescchützt wird
Um den Cluster aufzusetzen werde ich K3D verwenden.
Die Installation habe ich für Manjaro/Arch Linux bereits in dem Artikel K3D Cluster ausfsetzen beschrieben. Anmerkung: Die aktuelle Version kann nun mit yay bereits aus AUR gezogen werden.
Für diese Reihe erstelle ich einen kleinen Demo Cluster mit 2 Knoten und öffne den Port 8080 für den LoadBalancer. D.h. der NginX Reverse Proxy muss später auf den Host und Port 8080 verweisen, so dass die Anfragen vom KeyCloak dann beantwortet werden können.
k3d cluster create demo -a2 -p 8080:80@loadbalancer -p 8443:443@loadbalancer
Achtung: Die Syntax von K3D hat sich seit Version 3.0.0 geändert und folgt nun den anderen K8S Anwendungen, in dem es Nomen und Verb als Parameter verlangt. Bsp: aus k3d create cluster wurde nun k3d cluster create.
Wie immer sollte mna einen eigenen Namespace für die Trennung der Anwendung verwenden. Diesen legen wir zuerst mit:
k create namespace keycloak
an.
Hinweis: K ist bei mir immer ein Alias für kubectl.
Die Installation von Cert-Manager wird hier beschrieben.
Zunächst müssen wir ein Manifest erstellen, das einen Issuer und ein Certificate beschreibt. Die Domain wird hier auf *.clouster.local festgelegt.
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: selfsigned-issuer
spec:
selfSigned: {}
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: first-tls
spec:
secretName: first-tls
dnsNames:
- "*.cluster.local"
issuerRef:
name: selfsigned-issuer
Jetzt muss das Manifest angewendet werden und der Cert-Manager erstellt für uns das selbst signierte Zertifikat, welches wir in dem Ingress später referenzieren werden.
k apply -n keycloak -f keycloak-cert.yaml
Ein paar Schnelltests geben auskunft über die erfolgreiche Erstellung der Zertifikate:
# Zertifikat überprüfen
k -n keycloak get certificate
# Secret überprüfen
k -n keycloak get secret first-tls
Nun zum Abschluss noch mit OpenSSL überprüfen…
openssl x509 -in <(kubectl -n keycloak get secret first-tls -o jsonpath='{.data.tls\.crt}' | base64 -d) -text -noout
…in der Ausgabe erhält man dann die Informationen…
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2e:df:ae:86:5c:27:f9:25:bf:77:ca:d1:7a:3a:48:c6
Signature Algorithm: sha256WithRSAEncryption
Issuer:
Validity
Not Before: Sep 2 08:14:52 2020 GMT
Not After : Dec 1 08:14:52 2020 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c5:e0:f9:be:a6:b9:41:cb:38:e9:11:57:0a:1b:
b5:2b:c2:7e:78:87:5f:43:dc:22:c3:7d:8b:a7:f3:
c0:d4:f9:bc:75:4e:96:93:66:17:67:f7:e2:02:96:
37:19:90:64:6f:fa:c3:1f:c5:21:80:de:e0:aa:76:
12:d6:24:a0:f2:7b:37:14:34:a8:eb:9c:1a:17:b0:
4f:d8:a4:9b:3a:51:fe:18:30:3e:81:f5:20:01:85:
c1:af:61:cf:2e:30:fd:42:3c:00:c0:28:f9:60:37:
84:80:84:85:54:33:6c:0f:cb:c2:7e:5f:50:ee:82:
a1:4a:35:c3:5b:fe:8a:47:21:75:c5:0e:03:08:f2:
2d:fa:98:e8:d6:16:d6:fb:af:97:d8:86:3a:c6:84:
63:5d:bd:f1:1b:72:0f:73:f5:09:33:26:aa:bc:8f:
8c:9b:fa:a6:11:53:19:69:33:bc:68:47:c3:74:6a:
70:86:c5:19:93:83:cc:9e:07:11:0d:6e:9f:f8:5b:
67:d7:d8:ef:ca:37:4e:7c:1b:a2:f5:ee:70:eb:55:
2f:86:45:02:b4:4d:6d:9a:1b:20:3b:c4:d5:db:f3:
66:8c:22:e1:da:94:c4:e6:20:9f:c4:ff:79:b9:26:
b6:ae:d0:8f:f2:45:d5:7d:eb:88:7f:39:36:7d:ef:
f6:85
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name: critical
DNS:*.cluster.local
Signature Algorithm: sha256WithRSAEncryption
39:b5:cf:d7:08:b1:9d:07:44:ef:79:f3:13:46:11:f9:07:96:
f3:db:cb:8d:5e:df:14:5f:2f:74:ff:4a:c8:58:af:57:fa:35:
fb:19:1e:73:af:f5:d2:eb:ec:b9:d1:60:f5:28:c1:39:ba:a1:
0c:4e:0d:3c:10:83:ba:0f:ef:4f:7a:1c:68:25:3a:3c:bf:de:
04:24:f0:ca:15:34:6d:66:8f:3b:69:96:fe:b8:03:54:98:a6:
fe:b8:0f:d4:6f:1b:7a:87:6a:5a:c6:57:ff:62:ee:0f:24:ff:
e9:e8:e9:b5:4d:ca:ec:27:7c:03:7b:63:2e:ff:4d:3a:c8:5e:
d8:b4:f5:8a:e8:0c:2c:62:f1:00:c6:4d:fe:cf:45:e2:5b:74:
55:0a:fe:f7:5a:b4:c0:5a:2c:04:4c:ae:b2:5a:d3:d7:26:ca:
63:2c:69:2b:81:cd:6e:39:c4:66:5f:67:47:2d:f4:ea:eb:9b:
31:17:5d:4c:5b:77:26:d4:a4:4c:f1:52:ae:92:84:e9:f4:01:
7e:f1:f5:cf:1d:54:a5:8c:6b:58:b2:35:b3:44:0d:81:b6:da:
4e:0b:02:fe:21:21:75:59:53:15:17:67:7e:37:00:59:00:11:
67:47:4e:5f:0b:1d:c4:1e:4b:5c:d2:80:57:7f:2b:58:01:ba:
83:fc:c9:ce
Wir laden das Manifest keycloak.yaml mit wget runter und modifizieren die Defaultwerte für den Namespace und setzen ein neues Passwort. Der Namespace wird auf den zuvor erstellten Namespace keycloak gesetzt. Das Passwort wird auf 123 gesetzt.
wget -q -O - https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/kubernetes-examples/keycloak.yaml | sed "s/namespace: default/namespace: keycloak/" > keycloak.yaml
Achtung: Username und Passwort sind hier admin. Wer es sicherer mag, der sollte das YAML bearbeiten und die Werte ersetzen.
k apply -n keycloak -f keycloak.yaml
Das hochfahre der Pods kan mit
watch kubectl -n keycloak get pods
überwacht werden.
Da K3S in der Defaulteinstellung Traefik als Ingress Controller verwendet, nutze ich hier nicht die von KeyCloak Team bereitgestelltes Kubernetes Manifest für Ingress.
HTTPS Anfragen für die FQDN keycloak.cluster.local an den Cluster werden werden so an den Service keycloak an Port 8443 weitergeleitet.
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: selfsigned-issuer
spec:
selfSigned: {}
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: first-tls
spec:
secretName: first-tls
dnsNames:
- "*.cluster.local"
# - "*.keyclaok"
issuerRef:
name: selfsigned-issuer
Damit das Ganze funtkioniert, muss der FQDN keycloak.cluster.local in die /etc/hosts Datei eingetragen werden:
192.168.2.XXX keycloak.cluster.local
curl -k https://keycloak.cluster.local:8443
<!--
~ Copyright 2016 Red Hat, Inc. and/or its affiliates
~ and other contributors as indicated by the @author tags.
~
~ Licensed under the Apache License, Version 2.0 (the "License");
~ you may not use this file except in compliance with the License.
~ You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS,
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~ See the License for the specific language governing permissions and
~ limitations under the License.
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="refresh" content="0; url=/auth/" />
<meta name="robots" content="noindex, nofollow">
<script type="text/javascript">
window.location.href = "/auth/"
</script>
</head>
<body>
If you are not redirected automatically, follow this <a href='/auth'>link</a>.
</body>
</html>
Nun kann nach dem ersten erfolgreichen Test der KeyCloak über https://keycloak.cluster.local:8443/auth/ bzw. die Admin-Console über https://keycloak.cluster.local:8443/auth/admin/master/console/ aufgerufen werden. Die Credentials für die Admin-Console sind im Kubernetes Manifest (siehe oben) festgelegt worden.
Standard ist hier Username admin und Passwort admin.
Wie immer erstelle ich zunächst eine lokale Kopie des Manifests mit wget:
wget https://github.com/jetstack/cert-manager/releases/download/v0.16.1/cert-manager.yaml -q -O install.yaml
Nun können wir das Manifest anwenden. Wie bereits im Kommentar zu erkennen ist, ist es hier wichtig NICHT den Namespace bei apply anzugeben. Dieses führt später zu Fehlern und es lassen sich kein Zertifikate erstellen.
k apply -f install.yaml # Achtung hier kein Namespace angeben, da es sonst Fehler gibt
Den Abschluss des Deployments kann mit watch überwacht werden. Es sollte ziemlich schnell gehen, da die Anwendung relativ klein ist.
watch kubectl get pods --namespace cert-manager
Lazydocker macht das Handling mit Docker auf der Konsole einfach. Es bietet wie andere Tools K9S eine TUI.
Unter Manjaro ist die Installation mit yay recht einfach:
yay -S --noconfirm lazydocker
Lazydocker enthält die wichtigsten Funktionen, um schnell Container, Images und Volumes im Docker zu verwalten und von laufenden Container den Status abzufragen.
Dazu gehören die CPU und das Memory der Container, das Log, die Konfiguration und die TOP Prozesse.
Der Bildschirm ist zweispaltig aufgeteilt. In der linken Spalte befinden sich die Frames für das Projekt, Containers, Images und Volumes.
Mit den Tasten [ und ] lassen sich in den Frames zwischen den Tabs springen. Es kann aber auch die Maus genutzt werden.
Mit der Taste x lässt sich das Kontext-Menü öffnen. Hierüber lassen sich bequem die Funktionen erkunden.
Ein interresantes Feature sind die Bulk-Operations. Diese bieten in den unterschiedlichen Frames verschiedene Massenoperationen an. Z.B werden im Images Frames das Löschen den ungenutzten Images angeboten.
Eine Bulk Operation wird mit b gestartet. Ein Popupmenü gibt dann weitere Anweisungen.
Die Installation von ArgoCD ist sehr simple. Es wird nur ein Kubernetes Namespace benötigt. Das Installation YAML beziehen wir direkt von GitHub.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Wer mag der kann zunächst eine Kopie der install.yaml herunterladen und sie in einem Git Repository ablegen, so kann man immer wieder den Gleichen Zustand herstellen, auch wenn sich etwas an der online Version des YAMLs geändert haben sollte.
wget https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml -o install.yaml
kubectl apply -n argocd -f install.yaml
Die CLI Anwendung lässt sich schnell und einfach per yay installieren:
yay -S --noconfirm argocd-cli
#!/bin/bash
echo "username: admin"
echo "password: `kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2`"
# nur für localhost öffnen
k port-forward svc/argocd-server -n argocd 9010:443
# oder für alle offen
k port-forward --address 0.0.0.0 svc/argocd-server -n argocd 9010:443
Als Vorraussetzung muss der Paketmanager Helm in der neuen Verison 3 installiert sein.
yay -S helm
Es kann sein, dass das offiielle Repo mit den Helm Charts noch hinzugefügt werden muss. Das Offizielles Repo (siehe https://helm.sh/docs/intro/quickstart/ ) fügen wir mit
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
zu der Liste der Repositorys hinzu.
Ich nutze gern k als Alias für Kubectl und verwende es in Artikeln von mir. Wer will, kann folgendes in die .bashrc eintragen:
alias k=kubectl
Zunächst erstellen wir einen Namespace für Prometheus und Grafana.
k create namespace prometheus
Nun können Prometheus und Grafana in dem Cluster installiert werden.
helm install prometheus stable/prometheus-operator --namespace prometheus
Hinweiß: Alternativ kann auch der Parameter –create-namespace mit angegeben werden. So lässt sich ein Schritt einsparen
helm install prometheus stable/prometheus-operator --namespace prometheus --create-namespace
Den Status des Deployments überprüfen mit
k get pods -n prometheus
NAME READY STATUS RESTARTS AGE
prometheus-prometheus-node-exporter-cmmbs 1/1 Running 1 38m
prometheus-kube-state-metrics-c65b87574-pn7g2 1/1 Running 1 38m
prometheus-prometheus-node-exporter-6kb7d 1/1 Running 0 29m
prometheus-prometheus-node-exporter-vx7q7 1/1 Running 0 29m
prometheus-prometheus-node-exporter-cct7m 1/1 Running 0 38m
prometheus-prometheus-node-exporter-b4g7j 1/1 Running 1 38m
alertmanager-prometheus-prometheus-oper-alertmanager-0 2/2 Running 0 36m
prometheus-prometheus-node-exporter-kwfs5 1/1 Running 1 38m
prometheus-prometheus-node-exporter-b4smc 1/1 Running 1 38m
prometheus-prometheus-oper-operator-769d757547-mnjh7 2/2 Running 2 38m
prometheus-prometheus-prometheus-oper-prometheus-0 3/3 Running 1 36m
prometheus-prometheus-node-exporter-flk7s 1/1 Running 1 38m
prometheus-grafana-d6545c767-nxz4r 2/2 Running 0 38m
prometheus-prometheus-node-exporter-85zsp 1/1 Running 1 38m
Die genaue Bezeichnungen der Pods werden später für die Portweiterleitungen benötigt.
Nun öffnen wir mit dem Portfoward den Port 9090 für alle Adressen mit:
k port-forward -n prometheus prometheus-prometheus-prometheus-oper-prometheus-0 --address 0.0.0.0 9090
Nun muss der Port für (Pod Name muss angepasst werden. siehe oben)
k port-forward -n prometheus prometheus-grafana-d6545c767-5lfqz --address 0.0.0.0 3000
k get secret --namespace prometheus prometheus-grafana -o yaml
Mit OpenSSL dekodieren
openssl base64 -d
cHJvbS1vcGVyYXRvcg==
(STRG + d abschließen)
prom-operator
openssl base64 -d
YWRtaW4=
admin
Dashboard -> Manage
Port öffnen 8088 auf 8080
k port-forward -n prometheus prometheus-kube-state-metrics-c65b87574-56b58 8088:8080 --address 0.0.0.0
Nun im Browser http://10.10.20.190:8088/metrics öffnen und man erhält folgende Liste
# HELP kube_certificatesigningrequest_labels Kubernetes labels converted to Prometheus labels.
# TYPE kube_certificatesigningrequest_labels gauge
# HELP kube_certificatesigningrequest_created Unix creation timestamp
# TYPE kube_certificatesigningrequest_created gauge
# HELP kube_certificatesigningrequest_condition The number of each certificatesigningrequest condition
# TYPE kube_certificatesigningrequest_condition gauge
# HELP kube_certificatesigningrequest_cert_length Length of the issued cert
# TYPE kube_certificatesigningrequest_cert_length gauge
# HELP kube_configmap_info Information about configmap.
# TYPE kube_configmap_info gauge
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-node-rsrc-use"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-nodes"} 1
kube_configmap_info{namespace="kube-system",configmap="local-path-config"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-prometheus"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-kubelet"} 1
kube_configmap_info{namespace="liferay-prod",configmap="portal-ext.properties"} 1
kube_configmap_info{namespace="kube-system",configmap="traefik-test"} 1
kube_configmap_info{namespace="argocd",configmap="argocd-rbac-cm"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-pod-total"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-apiserver"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-workload"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-prometheus-oper-prometheus-rulefiles-0"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-node"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-workload-total"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-persistentvolumesusage"} 1
kube_configmap_info{namespace="kube-system",configmap="chart-values-traefik"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-pod"} 1
kube_configmap_info{namespace="kube-system",configmap="extension-apiserver-authentication"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-controller-manager"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-cluster-total"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-grafana-test"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-namespace-by-pod"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-scheduler"} 1
kube_configmap_info{namespace="kube-system",configmap="traefik"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-proxy"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-etcd"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-node-cluster-rsrc-use"} 1
kube_configmap_info{namespace="kube-system",configmap="coredns"} 1
kube_configmap_info{namespace="argocd",configmap="argocd-ssh-known-hosts-cm"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-grafana-datasource"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-cluster"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-statefulset"} 1
kube_configmap_info{namespace="argocd",configmap="argocd-cm"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-namespace"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-grafana"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-workloads-namespace"} 1
kube_configmap_info{namespace="argocd",configmap="argocd-tls-certs-cm"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-coredns"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-prometheus-oper-namespace-by-workload"} 1
kube_configmap_info{namespace="liferay-prod",configmap="elasticsearchconfiguration.cfg"} 1
kube_configmap_info{namespace="prometheus",configmap="prometheus-grafana-config-dashboards"} 1
# HELP kube_configmap_created Unix creation timestamp
# TYPE kube_configmap_created gauge
kube_configmap_created{namespace="prometheus",configmap="prometheus-prometheus-oper-statefulset"} 1.597903216e+09
kube_configmap_created{namespace="kube-system",configmap="coredns"} 1.597747102e+09
kube_configmap_created{namespace="argocd",configmap="argocd-ssh-known-hosts-cm"} 1.597747337e+09
kube_configmap_created{namespace="prometheus",configmap="prometheus-prometheus-oper-grafana-datasource"} 1.597903216e+09
kube_configmap_created{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-cluster"} 1.597903216e+09
kube_configmap_created{namespace="prometheus",configmap="prometheus-prometheus-oper-namespace-by-workload"} 1.597903216e+09
kube_configmap_created{namespace="liferay-prod",configmap="elasticsearchconfiguration.cfg"} 1.597834114e+09
kube_configmap_created{namespace="argocd",configmap="argocd-cm"} 1.597747337e+09
kube_configmap_created{namespace="prometheus",configmap="prometheus-prometheus-oper-k8s-resources-namespace"} 1.597903216e+09
Die Plugins Sharepoint REST und das Plugin für die ADFS Anbindung SAML2 benötigten ein spezielle Behandlung, da sie sonst einen Neustart des Osgi Runtime Containers benötigen. Diese ist bei der containercreation im Kubernetes Lifecylcle natürlich nicht möglich.
Zunächst habe ich die Plugins in ein Verzeichnis in dem Liferay Docker Container kopiert, der von Liferay überwacht wird und bei darf per hot deploy Bundles startet. In den Logs konnte man während des Startvorgangs auch erkennen das sie verarbeitet werden. So weit, so gut. Aber in den Logs tauchten Einträge auf, dass das Plugin für die Fertigstellung der Installation einen Neustart des Osgi Containers benötigt. Das ist eigentlich nicht die Philisofie von Osgi.
Neben dem bereit gennanten Verzeichnis gibt es ein weiteres Verzeichnis, welches Bundles verarbeitet. Es ist das Verzeichis marketplace. Dieses wird beim Starten von Liferay gesondert behandlet, so dass kein Neustart von Liferay nötig ist.
ConfigMaps in Kubernetes erlauben es Umgebungsvariablen in den Cluster zu mappen. Dieses kann auch genutzt werden, um Konfigurationsdateien in den Cluster zu bringen. Dazu kann man mit kubectl create configmap eine Datei angeben, die dann in der ConfigMap bereitgestellt wird.
Ich möchte hier einen weiteren Weg zeigen, wie man Dateien in den Cluster bekommt. Dazu nutzen wir das Feature Multi Line Collections von YAML, welches erlaubt mehrere Zeilen zuzuweisen. Hier also die Konfigurationsdatei.
Multi Line Collection werden mit einen Senkrechtstrich | eingeleitet. Es muss wie bei YAML üblich die Einrückung berücksichtigt werden.
Hier ein einfaches Beispiel aus dem Liferay Deployment. Es wird die Elasticsearch Konfiguration von Liferay in den Kubernetes Cluster gemappt.
apiVersion: v1
kind: ConfigMap
metadata:
name: elasticsearchconfiguration.cfg
namespace: liferay-prod
data:
com.liferay.portal.search.elasticsearch6.configuration.ElasticsearchConfiguration.cfg: |
operationMode="REMOTE"
indexNamePrefix="liferay-"
transportAddresses="search.liferay-prod.svc.cluster.local:9300"
clusterName="liferay_cluster"
logExceptionsOnly="false"
Diese Liste wird ständig von mir erweitert und unterliegt daher der Änderung.
| Name | Beschreibung | Homepage |
|---|---|---|
| minikube | Der Standard um Kubernetes lokal zu testen | https://minikube.sigs.k8s.io/docs/ |
| k3s | Minimale Kubernetes Cluster basierend auf einem einzigen Executable | https://k3s.io/ |
| k3d | Mit K3D kann man lokal ein Kubernetes Cluster aus mehreren Nodes innerhalb von Sekunden erzeugen. Intern werden Docker Container mit K3S, um die Nodes zu erzeugen. Es ist zu empfehlen hier auf das Beta der Version 3 zu wechseln. | https://github.com/rancher/k3d |
| k3sup | K3sup ist ein Tool um K3S lokal oder per SSH auf einem entfernten Rechner zu installieren. Da k3sup in GO geschrieben ist, besteht es auch nur aus einem Binary und besitzt keien weiteren Abhängigkeiten | https://github.com/alexellis/k3sup |
| k3c | https://github.com/rancher/k3c |
yay --noconfirm -S minikube k3s-bin rancher-k3d-beta-bin
| Name | Beschreibung | Homepage |
|---|---|---|
| k9s | Kommandoszeilentool mit dem man sehr einfach und schnell einen bestehenden Cluster untersuchen kann. Universelles Tool das man mit dem Kubernetes Dashboard für die Konsole vergleichen kann. | https://github.com/derailed/k9s |
| kubespy | ||
| kubectx | ||
| kubefwd | Findet alle Services in einem Namespace und erstellt ein Portforwarding für den Dienst ein und erstellt einen Eintrag in der /etc/hosts Datei, sodass sehr einfach auf die laufenden Dienste zugegriffen werden kann | https://github.com/txn2/kubefwd |
yay --noconfirm -S kubespy kubectx kubefwd-bin
| Name | Beschreibung | Homepage |
|---|---|---|
| stern | Mit Stern kann man die Logausgaben meherer Container in mehreren Pods ausgeben lassen. Für eine gute Unterscheidbarkeit werden die Ausgaben der verschiedenen Container in unterschiedlichen Farben eingefärbt. Dieses erlaubt ein schnelleres Debugging in komplexen Setups | https://github.com/wercker/stern |
yay --noconfirm -S stern-bin
| Name | Beschreibung | Homepage |
|---|---|---|
| tilt | Mit Hilfe von einem Autodeployment in ein Kubernetes Cluster, werden Codeänderungen sofort wirksam und es werden Fehler überrsichtlich in einer Web UI dargestellt. | https://tilt.dev/ |
yay -S --noconfirm tilt-bin