Currently, Obcerv installation is supported on Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE).
In the context of cloud Kubernetes environments like Amazon EKS, Google GKE, and Microsoft AKS, the concept of availability zones is related to the underlying infrastructure provided by the cloud service providers.
Availability zones are distinct and physically separated data centers within a specific region. They are designed to provide redundancy and fault tolerance by isolating resources and infrastructure components.
When installing Obcerv, it is recommended to configure the clusters to span across 1 or 3 availability zones. This means that the Kubernetes control plane and worker nodes will be distributed across multiple availability zones within the chosen region. Obcerv contains multiple stateful workloads that are configured to be distributed evenly across availability zones. For stateful workloads such as Timescale or Kafka using reserved nodes, it is important to evenly distribute them across availability zones. In a production environment, it is recommended to have 3 replicas of Timescale and Kafka. Hence, if the cluster spans across 3 availability zones, it is advised to distribute the 3 reserved nodes evenly across those zones.
If you have enabled readiness gates
on the namespace where Obcerv is installed in, an extra annotation must be added for the IAM/Keycloak Ingress:
alb.ingress.kubernetes.io/healthcheck-path: /auth/realms/master. This is used as a part of the readiness gate
health check to verify that the deployment has fully started. For example:
iam: ingress: annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:... alb.ingress.kubernetes.io/group.name: obcerv.mydomain.internal alb.ingress.kubernetes.io/ssl-redirect: "443" alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/healthcheck-path: /auth/realms/master