KUBERNETES WITH SWAMP
Swamp works with Kubernetes clusters through behaviors created from extension types. Each behavior is bound to a kubeconfig, a context and, for namespaced resources, a namespace. Running one of its methods reads or changes the cluster through the Kubernetes API, and the resources the method reads are stored as Swamp data that you can query, summarize and audit later.
Get started
curl -fsSL https://swamp-club.com/install.sh | sh swamp repo init swamp extension pull @swamp/kubernetes swamp extension pull @john/k8s swamp extension pull @bixu/k8s/execThe @swamp/kubernetes extension
Most Kubernetes work in Swamp goes through @swamp/kubernetes. It has a behavior type for each resource kind: pods, deployments, statefulsets, services, ingresses, configmaps, secrets, RBAC objects, persistent volume claims, network policies, horizontal pod autoscalers, jobs and cronjobs, events, nodes and namespaces. A sixteenth type, pod-summary, does not call the cluster. It aggregates pod data that a pod behavior has already stored. The methods use the same verbs as kubectl: list and get, create, update and delete, scale and restart, cordon and taint, fetch logs and exec into a container.
The extension also includes 14 workflows that combine these methods into repeatable diagnostics. Among them are cluster-health, deployment-status, service-connectivity, security-audit, rbac-audit, storage-health and debug-namespace-deep. The getting started tutorial pulls the extension and runs a pod behavior against a cluster for the first time. The task guides cover rolling out a new image to a deployment, cordoning a node for maintenance and summarizing pod health in a namespace.
Other Kubernetes extensions
The registry has three more Kubernetes extensions. Each one covers a narrower need:
- @john/k8s is a separately published toolkit with 15 behavior types and 13 workflows. Its methods are mostly the same as those in @swamp/kubernetes, but its types are named under @john/ and it has no statefulset type.
- @bixu/k8s/exec runs a command in one pod, or in parallel across every pod that matches a label selector. It requires the kubeContext global argument.
- @twonines/k8s-fleet checks the health of every context in a kubeconfig and combines the results into a fleet summary. Clusters it cannot reach appear in the summary as unreachable and do not stop the run.
Credentials and stored data
Behaviors authenticate through the kubeconfig on the machine that runs them. The kubeconfig and context global arguments select which file and which context to use. Read methods store what they find as Swamp data. Secret values are the exception: the secret get method stores decoded values in a vault, and secret list stores only key names. Understanding Kubernetes automation in Swamp explains how resource kinds map onto behavior types, what each run stores, and how to choose between these extensions.
Kubernetes documentation
Getting started with Kubernetes in Swamp
Pull the @swamp/kubernetes extension, create a pod behavior bound to a kubeconfig context and namespace, validate it, and run its first pod list method.
Tutorials →Roll out a new image to a Kubernetes deployment
Update a Kubernetes deployment's container image with a Swamp behavior, then check rollout conditions and ReplicaSet revisions to confirm the new version.
How-to Guides →Cordon a Kubernetes node for maintenance
Mark a Kubernetes node unschedulable with a Swamp node behavior, list the pods still running on it, apply a NoSchedule taint, and return it to service later.
How-to Guides →Summarize pod health in a Kubernetes namespace
Collect pods from a namespace with a pod behavior, then feed that stored data into a pod-summary behavior for counts by phase, node, restarts and health.
How-to Guides →Kubernetes extensions
Every Swamp extension for Kubernetes: behavior types, global arguments, methods, vault configuration and the data each one writes, read from the registry.
Reference →Understanding Kubernetes automation in Swamp
How Kubernetes resources map onto Swamp behavior types, stored data and bundled workflows, and the choices teams make about scope, contexts and extensions.
Explanation →