01
1. Prepare local cluster access
Make kubectl available on the Mac and confirm your existing Kubernetes configuration can read the target. Use credentials and permissions appropriate to the namespace. CTK does not create a cluster login or install kubectl for you.
The connector lists pods, deployments, stateful sets, daemon sets, services and endpoints. If a target returns no resources, it can also check that the namespace exists. An empty result and a forbidden read need different investigation.
02
2. Open watch setup
Connect the local repository associated with the workload. Choose Start watching, then Kubernetes. Check that your Team plan has room for the services it will observe.
Set Context to the intended kubeconfig context and Namespace to the namespace to inspect. An empty Context uses your current context, so specify it when you want the target to remain explicit. The local source folder does not filter the cluster resources; namespace is the remote scope.
03
3. Start and identify the resources
Choose Start watching and inspect Observe. Verify the target, service identity and timestamp in the evidence before interpreting a state. A local repository name is not proof that the selected namespace belongs to it.
A running container and a Ready pod answer different questions. CTK can also show available versus desired workload counts. These describe the Kubernetes resources it read, not a complete test of every application endpoint.
04
4. Investigate readiness or restart evidence
For a restart loop, compare the current container state with the recorded termination evidence. An OOMKilled reason supports an out-of-memory observation; a restart by itself does not.
Use Timeline for changes and Consistency to compare workload readings such as ready and desired replicas. A readiness failure can identify a failed probe without proving the deeper dependency responsible. Do further investigation in your normal Kubernetes tools.
05
5. Treat lost access as an observation gap
If the context, credentials or network become unavailable, check the connection status and last successful timestamp. Retained evidence is not a fresh statement that the workload is healthy.
Restore access outside CTK, then wait for a new successful reading. Stop watching when collection is no longer needed. This releases usage; it does not delete a namespace, scale a deployment or stop a pod.
06
What success looks like
The intended namespace produces identifiable, current observations. You can distinguish runtime state, readiness, workload availability and a failed connector read without treating any one of them as universal application health.
Know the limits
Kubernetes requires Team access. CTK reads resources through local kubectl; it does not deploy, restart or delete workloads.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles