Kubernetes Reference
The end-to-end install sequence lives in the Production Deployment Runbook. This page is the kubectl-level companion: the workloads the platform runs, and the commands to inspect and diagnose them once deployed. The runbook is authoritative for install and configuration; use this page to check a running deployment.
The platform requires a CNCF-conformant Kubernetes distribution. We support Amazon EKS (k3s for local development and evaluation only). Other distributions such as GKE or AKS are not validated and are not supported by default; contact Connamara to discuss one (see Version Compatibility). Where a cloud-specific choice arises (managed database, ingress controller, container registry), substitute the equivalent service from your provider.
What the platform runs
After a successful install, the namespace holds these workloads:
| Workload | Kind | Expected status | Default count |
|---|---|---|---|
conncentric-orchestrator-* | Deployment | Running | 2 |
conncentric-adapter-* | Deployment | Running | 4 |
conncentric-portal-* | Deployment | Running | 1 |
The install also runs two short-lived Jobs, a schema migration before the application pods and an installer afterwards. Both remove themselves on success, so a namespace with no Jobs left is the expected end state; either one is retained when it fails, which is when its log is worth reading.
Adapter pods that hold no lease report 0/1 Ready. That is expected: an idle adapter is a standby, not a fault. See Deployment Topologies.
Inspect a running deployment
The deploy/… and job/… names below track your Helm release name; if yours is not conncentric, run kubectl get deploy -n conncentric first to find the actual names.
# Workloads and pod health
kubectl get pods -n conncentric
# Logs for a specific pod (tail)
kubectl logs <pod-name> -n conncentric --tail=200
# Installer job result, available only if it failed (it removes itself on success).
# Pass 1 applies the base Essentials distribution and enabled plugins; Pass 2 applies any custom bundles from installer.customBundleUrls.
kubectl logs -l app.kubernetes.io/component=installer -n conncentric
# Orchestrator health (expect "status":"UP")
kubectl exec -it deploy/conncentric-orchestrator -n conncentric -- \
curl -sf http://localhost:8080/actuator/health
# Ingress routing (Portal reachability)
kubectl describe ingress -n conncentric
Troubleshooting
| Symptom | Likely cause | Action |
|---|---|---|
Orchestrator pod in CrashLoopBackOff | Database unreachable or wrong credentials | Check database.* values; test DNS from a pod: kubectl exec -it <pod> -n conncentric -- nslookup <db-host> |
| Portal loads but shows "Unable to reach the server" | Ingress not routing /api to the Orchestrator | kubectl describe ingress -n conncentric and confirm the backend and path |
| Adapter pods running but no connectors or components offered in the Portal | Installer job did not complete | A failed installer job is retained, so read its log with kubectl logs -l app.kubernetes.io/component=installer -n conncentric; re-run with helm upgrade conncentric oci://<your-registry>/conncentric/charts/conncentric --version <release-tag> -n conncentric -f values.production.yaml |
For OIDC sign-in failures see Authentication; for broader diagnostic patterns see Troubleshooting.
See also
- Production Deployment Runbook - the full install and verify sequence
- Helm Reference - every configurable value
- Upgrades - the rolling-upgrade procedure