Connect a Kubernetes cluster

Before you begin

A Remote Agent collects logs and container metrics and sends them to your LogForge server. ECHO in generated settings or filenames means this agent; keep those literal names unchanged.

• Release: use only a Kubernetes combination qualified for your supplied release. LogForge must be reachable and offer an immutable agent image.
• Access: the LogForge server Owner or permission to connect agents, plus cluster-admin permissions described below.
• Where: Bash on a workstation with kubectl, Helm 3, and access to the intended Kubernetes 1.32+ cluster. Use a private working directory.

Have your cluster administrator confirm:

• Permission to create the namespace, enrollment Secret, public certificate ConfigMap, service accounts, cluster read permissions, Deployment, DaemonSet, Service, and persistent state claim.
• A working default storage class. Default buffers request 2 GiB; larger buffers increase this. Node workers also keep local state.
• Worker access to node logs and kubelet metrics. The kubelet is the node service supplying Pod/container statistics.
• Controller connectivity to your server's HTTPS and mutual TLS addresses, and node access to the exact images.

Kind: also install kind, Docker, and OpenSSL. The script prepares public kubelet trust for local nodes. Other clusters using a separate kubelet certificate authority need its public certificate ConfigMap in the generated namespace before installation.

Keep enrollment private: generated material contains a one-time credential. Exclude it from shell history, screenshots, tickets, and source control. Never disable certificate verification.

Select the cluster explicitly

In your private working directory, list contexts. A context selects the cluster and credentials used by your tools:

kubectl config get-contexts

Replace the example name, then check:

export UNICRON_ECHO_KUBE_CONTEXT=your-cluster-context
kubectl --context "$UNICRON_ECHO_KUBE_CONTEXT" cluster-info
helm version --short

Check: the intended cluster responds and Helm reports v3. Keep the value exported in the same Bash session as the installer. Without it, the tools' current context is used.

Disconnected clusters: obtain a release-approved initial installation procedure, including image registry access, node trust and pull credentials. The server archive alone does not prepare the cluster. Do not infer a first-install procedure from the native updater's separate internal-registry option.

Release scope: published October 28 AMD64/ARM64 Docker packages do not establish Kubernetes update or real ARM-host qualification. Confirm your exact Kubernetes combination with LogForge before using this path.

Generate and install

The product calls the generated installation files an artifact. They contain the command and settings for this agent. Keep the generated names and commands unchanged.

1. Open Overview > Hosts > Add remote agent in the LogForge server.
2. Select Install target: Kubernetes Helm. Review Remote Agent display name, Kubernetes environment, and Reason for this action.
3. Choose Create Kubernetes install artifact. Check the namespace, release, storage request, and exact image.
4. If using a separate kubelet CA ConfigMap, confirm it exists in that namespace, then export its name and key in the same Bash session:

export UNICRON_ECHO_KUBELET_TRUST_CONFIGMAP=your-kubelet-ca
export UNICRON_ECHO_KUBELET_TRUST_BUNDLE_KEY=ca.crt

5. Choose Copy Kubernetes install script. Run it unchanged in that Bash session. It includes the chart and prepares temporary files; no source checkout is needed.
6. Keep the wizard open until first authenticated connection. Use its status commands to inspect the Helm release and controller/worker Pods.

The script installs one enrolling controller and non-enrolling node workers. Keep its image, release, namespace, identity, and permissions unchanged.

Verify collection

1. Check the connected agent, cluster environment, fresh inventory, and Health in the LogForge server.
2. Select a known workload. Enable Monitor logs and alerts and produce a harmless log event.
3. Check saved history in Logs and recent Pod/container samples in Metrics. Metrics do not depend on log monitoring.
4. Revisit and query the saved evidence. Remove private copies of the one-time artifact after check-in.

Success means saved data: Pod startup alone is insufficient. Kubernetes Terminal and Files access are not implemented.

If installation or collection fails

Problem: wrong cluster, pending/failed Pods, or missing data.

Why it matters: context, storage, image access, trust, and enrollment are separate requirements.

Next step:

• Stop before applying to the wrong cluster.
• Use generated diagnostics. Check storage claims, image pulls, both agent connection addresses, and kubelet trust.
• Preserve the namespace, enrollment Secret, state claim, and identity.
• For expired artifacts or uncertain partial installs, inspect Settings > Remote Agent deployments and its recovery action.

Do not repeatedly enroll, delete state, or uninstall while diagnosing. For version changes, use Updates and recovery.