Static YAML Manifests Deployment
Relevant source files
The following files were used as context for generating this wiki page:Static YAML Manifests Deployment provides a mechanism to install Kuberhealthy into a Kubernetes cluster using pre-rendered, "flat" spec files. This approach serves as an alternative to Helm, allowing users to deploy the operator and its core components using standard kubectl apply commands without the overhead of a package manager. Sources: deploy/README.md:1-10, README.md:85-90
These manifests are automatically updated to reflect the most recent changes in the master branch, making them ideal for testing the latest features or for environments where Helm is not permitted. The deployment scope covers the Kuberhealthy operator, necessary Custom Resource Definitions (CRDs), and basic synthetic checks. Sources: deploy/README.md:6-10, README.md:112-115
Deployment Workflow and Resource Orchestration
The deployment process follows a specific order of operations to ensure the operator can observe and manage synthetic check resources. Users must first establish the target namespace before applying the flattened configuration files.
The diagram shows the sequence from initial namespace creation to the operator becoming operational within the cluster. Sources: deploy/README.md:4-10, README.md:92-104
Manifest Variants
Kuberhealthy provides three primary static manifest variants tailored to specific monitoring stack requirements:
| Manifest File | Target Environment | Key Components Included |
|---|---|---|
kuberhealthy.yaml | Non-Prometheus Clusters | Operator, basic checks, CRDs, Service (ClusterIP) |
kuberhealthy-prometheus.yaml | Standard Prometheus | All basic components + Prometheus-specific annotations |
kuberhealthy-prometheus-operator.yaml | Prometheus Operator | All basic components + ServiceMonitor/PrometheusRule definitions |
Sources: deploy/README.md:12-30, README.md:92-104
Core Deployment Specification
The static manifests define an apps/v1 Deployment that manages the Kuberhealthy operator pods. The specification includes robust failover configurations and security contexts required for cluster-wide operation.
Pod Configuration and Failover
The deployment typically defaults to 2 replicas to ensure high availability and failover capacity. It uses a RollingUpdate strategy to prevent downtime during configuration reloads or image updates. Sources: deploy/helm/kuberhealthy/templates/deployment.yaml:16-21, deploy/helm/kuberhealthy/values.yaml:104-106
- Replicas: 2 (failover capacity)
- Strategy: RollingUpdate (MaxSurge: 0, MaxUnavailable: 1)
- Port: 8080 (HTTP status page and metrics)
- Volumes: A ConfigMap named
kuberhealthyis mounted to/etc/config/to provide operational parameters.
Sources: deploy/helm/kuberhealthy/templates/deployment.yaml:26-31, deploy/helm/kuberhealthy/templates/deployment.yaml:85-88, deploy/helm/kuberhealthy/values.yaml:113-115
Security and Runtime Context
The operator is configured to run with restricted privileges by default to adhere to Kubernetes security best practices.
securityContext:
runAsNonRoot: true
runAsUser: 999
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
Sources: deploy/helm/kuberhealthy/templates/deployment.yaml:90-95, deploy/helm/kuberhealthy/values.yaml:138-142
Custom Resource Definitions (CRDs) Deployment
Before synthetic checks can be executed, the cluster must recognize the KuberhealthyCheck (khcheck) and KuberhealthyJob (khjob) resources. These are bundled into the static manifests to facilitate immediate functionality.
KuberhealthyCheck Structure
The CRD defines the lifecycle of a synthetic test, including how often it runs and its resource constraints.
- Group:
comcast.github.io - Scope: Namespaced
- Key Fields:
runInterval: Frequency of check execution.timeout: Maximum allowed time for the check to complete.podSpec: A standard Kubernetes Pod template used to spawn the checker pod.
Sources: deploy/helm/kuberhealthy/crds/comcast.github.io_khchecks.yaml:12-25, deploy/helm/kuberhealthy/crds/comcast.github.io_khchecks.yaml:45-55
Deployment Logic for Synthetic Checks
When the static manifests are applied, they often include initial checks (e.g., deployment-check). The operator uses the following sequence to execute these tests:
This diagram illustrates the internal logic triggered by applying a static YAML that includes check definitions. Sources: README.md:130-145, cmd/deployment-check/README.md:15-30
Summary
The Static YAML Manifests Deployment provides a streamlined path for integrating Kuberhealthy into clusters without package management dependencies. By offering specific variants for different monitoring environments, it ensures that metrics and service monitoring are pre-configured, while the core deployment maintains high availability and strict security defaults. Sources: deploy/README.md:1-5, README.md:106-110