OpenShift

Check agent status per state watch -d "oc get agent -A -o jsonpath='{range .items[*]}{@.status.debugInfo.state}{\"\n\"}{end}' |sort | uniq --count"

During the last months, I’ve been working with my colleagues on setting up a workflow that can be used to deploy Spoke clusters in an automated way. More or less, the idea behind this is that a cluster is configured via a set of configuration files and templates so that the required components are installed: Advanced Cluster Management (ACM) Quay registry OpenShift Data Foundation OpenShift Pipelines (a.k.a. Tekton) etc Once the system was configured, it would become a ‘Hub’, and from it, several ‘Spokes’ could be deployed using ACM, getting them configured in the process to become a cluster suitable for fully-disconnected operation....

Introduction In a regular OpenShift environment, NTP server is more less like this: Diagram In a self-contained cluster with no connection to external networks NTP server is not reachable, but a reachable NTP server is required for proper cluster synchronization. Cluster does use SSL certificates that require validation and might fail if the dates between the systems are not in sync or at least pretty close in time. Diagram We’ve several components already available in our OpenShift cluster that are very useful:...

This article was published originally at https://metal3.io/blog/2019/09/11/Baremetal-operator.html Introduction The baremetal operator, documented at https://github.com/metal3-io/baremetal-operator/blob/master/docs/api.md, it’s the Operator in charge of definitions of physical hosts, containing information about how to reach the Out of Band management controller, URL with the desired image to provision, plus other properties related with hosts being used for provisioning instances. Quoting from the project: The Bare Metal Operator implements a Kubernetes API for managing bare metal hosts....

Postgres across clusters For Postgres to work across clusters we do need to have the data being synchronized. With some other databases we do have some master-master approach, but usually have very strict requirements on latency, bandwidth, etc that we cannot solve with On-Premise + external cloud providers. If the replication is based on the storage level instead, then you face that database servers don’t deal well if the data changes underneath it, so it leads to data corruption, on top of the storage-level issues/requirements as well on bandwidth, latency, etc....