Prometheus and Grafana are the top tools when it comes to monitoring and alarming in a cloud-native environment. But as powerful as the tools are, the configuration effort can also be extensive. In Rancher 2.5, the previously integrated Prometheus Monitoring has been completely revised. With Prometheus Operator there is already a ready-made solution for the cluster owner. The project owner can create his own monitoring instance and manage it according to his needs.
Prometheus und Grafana sind die Top-Tools, wenn es im cloud-nativen Umfeld um Monitoring und Alarming geht. Aber so mächtig die Tools sind, so umfangreich kann auch der Konfigurationsaufwand werden. In Rancher 2.5 wurde das bislang integrierte Prometheus Monitoring komplett überarbeitet. Mit Prometheus Operator gibt es schon eine fertige Lösung für den Cluster-Owner. Der Project-Owner kann seine eigene Monitoring-Instanz erstellen und diese nach seinen Ansprüchen verwaltet.
Eigentlich sollten sich die OpenStacker wieder in Berlin treffen. Wieder im Herbst, wie vor 2 Jahren. Das Wetter ist etwas schlechter und fast haette man den neuen Flughafen BER nutzen koennen. Aber es kam alles ganz anders, 2020 - im Jahr der Ratte, Corona machte alle physische Praesenz zunichte. Im Mai bei der Vorplanung ging man noch von Besserung aus. Die Entscheidung fuer das virtuelle Event war die richtige, man wird wohl noch eine Weile damit leben muessen.
Was kann es besseres geben als einen Kubernetes Cluster? Richtig: ZWEI Kubernetes Cluster! Optimalerweise sollten diese sich miteinander unterhalten koennen und man sollte Arbeitslast leicht von einem Cluster auf einen anderen verschieben koennen.
Die Antwort dazu heisst: KubeFed
Github bietet seit einiger Zeit jetzt schon das Feature "Action" an - ein CI/CD-Werkzeug, was noch bischen ein Nischendasein fristet neben den ganzen anderen Platzhirschen wie Travis, CircleCI usw. Voellig unbegruendet! Heute zeige ich Euch, wie man in 5 Minuten Github Action Pipeline erfolgreich einrichtet, um eine Applikation in einem Kubernetes-Cluster neu zu deployen.
Wer sich ueber die Install Quickies mit Minikube oder K3S einen Kubernetes-Cluster hochgezogen hat, hat meistens keine Probleme beim Adminzugriff mit kubectl - der allumfassende Superuser-Account ist meist bei der Installation mit dabei. Wie sieht es aber auch, wenn wir andere Benutzer aufs System lassen wollen? Oder Maschinenaccounts, die nur bestimmte Aktionen ausfuehren sollen? Zeit fuer einen Ausflug zu RBAC und der Authentifizierung in Kubernetes
Automation in the IT landscape is a long-term goal. With tools such as Puppet, Chef or Ansible, the operator takes the approach of leaving recurring processes to the computer. Or roll out predefined states of environments in the data center. Since DevOps at the latest, however, the entire value chain and the life cycle of an application must always be considered.
Automatisierung in der IT-Landschaft ist ein langverfolgtes Ziel. Mit Werkzeugen wie Puppet, Chef oder Ansible verfolgt der Operator den Ansatz, immer wiederkehrende Ablaeufe dem Computer zu ueberlassen. Oder vordefinierte Zustaende von Umgebungen im Serverpark auszurollen. Spaetestens seit DevOps ist dabei aber immer die komplette Wertschoepfungskette und damit der Lebenszyklus einer Applikation zu betrachten.
In Backup mein Kubernetes, aber sicher haben wir uns schon mal mit dem Thema Backups auseinandergesetzt. Es ging dabei um Kubernetes Resourcen, die irgendwie mal angelegt worden sind, aber man weiss nicht mehr genau wie und von wem. Zeit sich eine neue Backuploesung anzusehen, mit der auch Volumes gesichert werden koennen, am besten nach S3-Speicher
Nachdem man sich schon etwas mit Kubernetes vertraut gemacht hat, fallen einem vielleicht schon sinnvolle Anwendungsbeispiele ein. Zeit sich einen Kubernetes Cluster zu beschaffen, gern als "Managed Kubernetes", wie das Angebot heutzutage heisst. Als Privatanwender muss man aber schon recht tief in die Tasche greifen - im Vergleich zum V-Server oder Root-Server