Manchmal, wenn ich so richtig voller Freude darüber bin, dass ich alles aus einer Hand bekomme, dann werde ich gestoppt von so richtig bekloppten Fehlern.
So auch bei der Verwendung des Helm Providers in Terraform. Es ist ja wirklich super, wenn man nicht das Toolset wechseln muss, um sein Zeug zu erledigen.
Terraform ist auch so eine geniale Software, dass ich fast alles damit "as code" machen kann. Unter anderem auch Helm deployments - was super ist, dann so verlasse ich zum einen nicht das Ökosystem, zum anderen brauche ich informationen nicht weitergeben.
Doch was ist, wenn du alles richtig zu machen scheinst, aber ein Terraform apply dir den Dienst mit einer Fehlermeldung wie
helm_release.nginx_ingress: Creating...
╷
│ Error: could not download chartquittiert?
Dann, mein lieber Freund, hast du vermutlich einfach kacke in deinem lokalen Helm Repo Dingens. Denn wenn man ein HELM_DEBUG=1 in den Umgebungsvariablen zeigt die dann, was Sache ist. In meinem Fall war es ein kaputtes repo von irgendeiner mega-software. Repo gelöscht, alles geil
Hat mich auch nur 5 Stunden gekostet... oder so!
Letztens hatte ich eine halbwegs interessante Aufgabe: Ein bereits getätigtes Deployment in einem Kubernetes Cluster soll um die eigene Konfiguration erweitert werden. Dabei wird einem jedoch nicht die Möglichkeiet gegeben eine eigene Configmap oder sowas zu definieren.
Was kann man in einem solchen Fall tun? Wir können nun ganz stumpf die vorhandene Configmap kopieren, mit unseren Werten ergänzen und das Original überschreiben.
Kann man machen, ist dann halt kacke!
Auf diese Weise kriegen wir natürlich keine Updates von dem Deployment mit, sofern welche eingespielt werden. Was geht also noch?
Patchen!
Geil - ich kann den Teil der YAML nachbauen, den ich ergänzt/gepatcht haben will und diesen dann einfach mit kubectl drauf hauen - damit die die vorhandene Resource nur... gepatcht und nicht überschrieben!
kubectl patch configmap MYFANCYCONFIGMAP -n K8SNAMESPACE --patch-file./PATCHFILE.yamlIch bin begeistert!
Ja ja... ihr seid genau so gelangweilt von Kubernetes wie ich.. naja, nicht ganz. Aber Kubernetes ist halt überall und auch wenn man sich manches anders wünscht, kann man sich doch schon nette Dinge damit bauen.
Leider finde ich, dass der OnPrem Bereich ein wenig zu wenig aufmerksamkeit bekommt. Hier würde ich zwar auch gern ein Nomad anstelle eines Kubernetes sehen - aber seien wir mal gnädig. Nicht jeder Starbucks-Hipster-Admin kann sowas.
Wenn man nun allerdings sein Kubernetes ohne so hippen Cloud Kram betreibt, dann kommt man an den Punkt, an dem man feststellt, dass diese LoadBalander Sache echt cool wäre - wenn man sie denn hätte.
Ich gehe jetzt davon aus, das der Leser dieses Beitrages bereits das Verständnis hat, dass ein LoadBalancer in Kubernetes eine verwaltete Resource in einer Cloudumgebung ist. Will man das im eigenen Netzwerk haben, braucht man entweder auch so Spielzeug, oder man baut es nach.
Hier kommt kube-vip ins spiel. Es macht ähnlich to Metall-lb ein wenig Magie mit Netzwerk und sorgt so dafür, dass die sorgsam hoch verfügbar aufgestellten Resourcen auch über lokale IP-Adressen erreicht werden können. Will man also z.B. 3 Controlplane Server betreiben, wird eine neue Adresse (LoadBalander) verwendet, der dann eben dafürt sorgt, dass im Falle eines Ausfalls die anderen Server genutzt weden. Natürlich kann man auch einfach seine Services damit ausstatten und so im Netzwerk verfügbar machen.
Insgesamt ist es ein nettes Tool, das Kubernetes ins lokale Netzwerk bringen kann.
Quellen und Links