kubernetes.core<\/code> collection does all of that declaratively, from the same control node, in the same playbook language.<\/p>\n\nThis guide covers both. We provision a kubeadm cluster with a set of Ansible roles, then manage real workloads on it with kubernetes.core<\/code>: a Deployment, a Helm release, a node drain, and a worker added live. If Ansible itself is new on your control node, set it up first with the install Ansible guide<\/a>; this article is part of the wider Ansible automation guide<\/a>.<\/p>\n\nRun in June 2026 on Ubuntu 24.04 with Kubernetes 1.36 and the kubernetes.core 6.4 collection.<\/em><\/p>\n\nHow Ansible and Kubernetes fit together<\/h2>\n\n
Keep the two jobs separate in your head, because they use different tools.<\/p>\n\n
Provisioning<\/strong> runs against the nodes over SSH. Ansible becomes root, installs packages, and shells out to kubeadm. This is ordinary server automation that happens to end in a cluster. Management<\/strong> runs against the Kubernetes API, not the nodes. The kubernetes.core<\/code> modules talk to the API server with the Python Kubernetes client, so they run on the control node itself and need a kubeconfig, not SSH. One repo holds both: roles for the first job, playbooks in a manage\/<\/code> directory for the second.<\/p>\n\nLab layout<\/h2>\n\n
Four machines, all Ubuntu 24.04:<\/p>\n\n
\n- Ansible controller<\/strong>, where you run the playbooks. It never joins the cluster.<\/li>\n
- One control-plane node<\/strong> (the kubeadm “first” node).<\/li>\n
- Two worker nodes<\/strong> to start. We add a third later without touching the first two.<\/li>\n<\/ul>\n\n
The controller reaches every node as a sudo-capable user over an SSH key, which is the only prerequisite the roles assume. Give each node 2 vCPU and at least 2 GB of RAM; the control plane is happier with 4 GB. kubeadm refuses to start on a single CPU.<\/p>\n\n
Set up the Ansible controller<\/h2>\n\n
The controller needs Ansible, the Python Kubernetes client in the same<\/em> environment Ansible runs from, the kubernetes.core<\/code> collection, and Helm. Install pipx, then layer the pieces on top:<\/p>\n\n\nsudo apt update\nsudo apt install -y pipx python3-venv\npipx install --include-deps ansible\npipx inject ansible kubernetes\nansible-galaxy collection install kubernetes.core\ncurl -fsSL https:\/\/raw.githubusercontent.com\/helm\/helm\/main\/scripts\/get-helm-3 | bash<\/code><\/pre>\n\n\nThe pipx inject<\/code> step is the one people miss. The kubernetes.core<\/code> modules import the kubernetes<\/code> Python library at runtime, and they look for it in Ansible’s own virtualenv. Installing it with a separate pip<\/code> puts it somewhere Ansible cannot see, and every task fails with “Failed to import the required Python library (kubernetes)”. Inject it into the Ansible venv and the problem disappears.<\/p>\n\nConfirm the collection and client are both present:<\/p>\n\n\n
ansible-galaxy collection list | grep kubernetes<\/code><\/pre>\n\n\nThe collection and its version print on a single line:<\/p>\n\n\n
kubernetes.core 6.4.0<\/code><\/pre>\n\n\nThat confirms the collection and its Python client are both visible to Ansible, which is the combination the management playbooks depend on later.<\/p>\n\n
Build the inventory<\/h2>\n\n
Group the nodes into a control plane and workers. The roles key off these group names, so the names matter.<\/p>\n\n\n
[control_plane]\nk8s-cp1 ansible_host=192.168.1.168\n\n[workers]\nk8s-w1 ansible_host=192.168.1.169\nk8s-w2 ansible_host=192.168.1.170\n\n[k8s_cluster:children]\ncontrol_plane\nworkers<\/code><\/pre>\n\n\nA handful of cluster-wide settings live in group_vars\/all.yml<\/code>. This is also where the one networking decision that bites people gets made.<\/p>\n\n\n---\n# Kubernetes minor version. This is the pkgs.k8s.io repo path; bump it to upgrade.\nk8s_minor: "v1.36" # https:\/\/kubernetes.io\/releases\/\n\n# Pod network CIDR handed to kubeadm and Calico.\n# MUST NOT overlap your node\/LAN subnet (the lab nodes are on 192.168.1.0\/24).\npod_network_cidr: "10.244.0.0\/16"<\/code><\/pre>\n\n\nThe pod network CIDR must not overlap the subnet your nodes sit on. Calico’s own default is 192.168.0.0\/16<\/code>, and plenty of home and office LANs live inside that range. If they overlap, pod traffic and node traffic fight over the same addresses and routing breaks in ways that are miserable to debug. The lab nodes here are on 192.168.1.0\/24<\/code>, so the pods get 10.244.0.0\/16<\/code> instead. Pick any private range that your network does not already use.<\/p>\n\nPrepare every node<\/h2>\n\n
The common<\/code> role runs on the whole cluster and does everything kubeadm expects to already be true: swap off, the bridge and overlay modules loaded, the networking sysctls set, containerd installed with the systemd cgroup driver, and the Kubernetes packages held at a fixed version.<\/p>\n\n\n---\n# Prereqs that every node (control plane and workers) needs before kubeadm runs.\n\n- name: Disable swap for the running session\n ansible.builtin.command: swapoff -a\n changed_when: false\n\n- name: Disable swap permanently in fstab\n ansible.posix.mount:\n path: "{{ item }}"\n state: absent\n loop:\n - swap\n - none\n when: ansible_swaptotal_mb | int > 0\n\n- name: Load kernel modules now\n community.general.modprobe:\n name: "{{ item }}"\n state: present\n loop:\n - overlay\n - br_netfilter\n\n- name: Load kernel modules on boot\n ansible.builtin.copy:\n dest: \/etc\/modules-load.d\/k8s.conf\n content: |\n overlay\n br_netfilter\n mode: "0644"\n\n- name: Apply sysctl settings for Kubernetes networking\n ansible.posix.sysctl:\n name: "{{ item.key }}"\n value: "{{ item.value }}"\n sysctl_file: \/etc\/sysctl.d\/k8s.conf\n reload: true\n loop:\n - { key: net.bridge.bridge-nf-call-iptables, value: "1" }\n - { key: net.bridge.bridge-nf-call-ip6tables, value: "1" }\n - { key: net.ipv4.ip_forward, value: "1" }\n\n- name: Install containerd and apt prerequisites\n ansible.builtin.apt:\n name:\n - containerd\n - apt-transport-https\n - ca-certificates\n - curl\n - gpg\n state: present\n update_cache: true\n\n- name: Create containerd config directory\n ansible.builtin.file:\n path: \/etc\/containerd\n state: directory\n mode: "0755"\n\n- name: Generate default containerd config\n ansible.builtin.shell: containerd config default > \/etc\/containerd\/config.toml\n args:\n creates: \/etc\/containerd\/config.toml\n\n- name: Use the systemd cgroup driver in containerd\n ansible.builtin.lineinfile:\n path: \/etc\/containerd\/config.toml\n regexp: '^(\\s*)SystemdCgroup\\s*='\n line: ' SystemdCgroup = true'\n notify: Restart containerd\n\n- name: Add the Kubernetes apt signing key\n ansible.builtin.get_url:\n url: "https:\/\/pkgs.k8s.io\/core:\/stable:\/{{ k8s_minor }}\/deb\/Release.key"\n dest: \/etc\/apt\/keyrings\/kubernetes-apt-keyring.asc\n mode: "0644"\n\n- name: Add the Kubernetes apt repository\n ansible.builtin.apt_repository:\n repo: "deb [signed-by=\/etc\/apt\/keyrings\/kubernetes-apt-keyring.asc] https:\/\/pkgs.k8s.io\/core:\/stable:\/{{ k8s_minor }}\/deb\/ \/"\n filename: kubernetes\n state: present\n\n- name: Install kubelet, kubeadm and kubectl\n ansible.builtin.apt:\n name:\n - kubelet\n - kubeadm\n - kubectl\n state: present\n update_cache: true\n\n- name: Hold the Kubernetes packages at their current version\n ansible.builtin.dpkg_selections:\n name: "{{ item }}"\n selection: hold\n loop:\n - kubelet\n - kubeadm\n - kubectl\n\n- name: Enable and start kubelet\n ansible.builtin.systemd:\n name: kubelet\n enabled: true\n state: started\n\n- name: Flush handlers so containerd restarts before kubeadm runs\n ansible.builtin.meta: flush_handlers<\/code><\/pre>\n\n\nOne edit earns its place above all the others. Containerd ships with SystemdCgroup<\/code> set to false, and on a systemd host it has to be true, or the kubelet and containerd disagree about who owns the cgroups and pods never leave ContainerCreating<\/code>. On containerd 2.x the setting lives under the CRI runc options in \/etc\/containerd\/config.toml<\/code>, which is why the role regenerates the default config first and edits that one line. The apt-mark hold<\/code> at the end stops an unattended apt upgrade<\/code> from dragging the cluster to a new minor behind your back.<\/p>\n\nBring up the control plane<\/h2>\n\n
The control_plane<\/code> role initialises the cluster, installs a kubeconfig for your login user, lays down the Calico CNI, and prints a join command the workers pick up. It is written to be safe to run twice: the creates:<\/code> guard on kubeadm init<\/code> means a second run never re-initialises a live cluster.<\/p>\n\n\n---\n# Initialise the control plane, lay down kubeconfig, install Calico, and\n# publish a join command the workers will pick up.\n\n- name: Check whether the control plane is already initialised\n ansible.builtin.stat:\n path: \/etc\/kubernetes\/admin.conf\n register: kubeadm_admin\n\n- name: Pull control-plane images ahead of init\n ansible.builtin.command: kubeadm config images pull\n when: not kubeadm_admin.stat.exists\n changed_when: true\n\n- name: Initialise the cluster with kubeadm\n ansible.builtin.command: >\n kubeadm init\n --pod-network-cidr={{ pod_network_cidr }}\n --apiserver-advertise-address={{ ansible_host }}\n --node-name={{ inventory_hostname }}\n args:\n creates: \/etc\/kubernetes\/admin.conf\n register: kubeadm_init\n\n- name: Create .kube directory for the login user\n ansible.builtin.file:\n path: "\/home\/{{ ansible_user }}\/.kube"\n state: directory\n owner: "{{ ansible_user }}"\n group: "{{ ansible_user }}"\n mode: "0750"\n\n- name: Install kubeconfig for the login user\n ansible.builtin.copy:\n src: \/etc\/kubernetes\/admin.conf\n dest: "\/home\/{{ ansible_user }}\/.kube\/config"\n remote_src: true\n owner: "{{ ansible_user }}"\n group: "{{ ansible_user }}"\n mode: "0600"\n\n- name: Detect the latest Calico release\n ansible.builtin.uri:\n url: https:\/\/api.github.com\/repos\/projectcalico\/calico\/releases\/latest\n return_content: true\n register: calico_release\n\n- name: Set the Calico version fact\n ansible.builtin.set_fact:\n calico_version: "{{ calico_release.json.tag_name }}"\n\n- name: Install the Calico operator CRDs\n ansible.builtin.command: >\n kubectl --kubeconfig \/etc\/kubernetes\/admin.conf apply --server-side --force-conflicts\n -f https:\/\/raw.githubusercontent.com\/projectcalico\/calico\/{{ calico_version }}\/manifests\/operator-crds.yaml\n register: crds_apply\n changed_when: "'created' in crds_apply.stdout or 'configured' in crds_apply.stdout"\n\n- name: Install the Tigera (Calico) operator\n ansible.builtin.command: >\n kubectl --kubeconfig \/etc\/kubernetes\/admin.conf apply --server-side --force-conflicts\n -f https:\/\/raw.githubusercontent.com\/projectcalico\/calico\/{{ calico_version }}\/manifests\/tigera-operator.yaml\n register: tigera_apply\n changed_when: "'created' in tigera_apply.stdout or 'configured' in tigera_apply.stdout"\n\n- name: Wait for the Installation CRD to register\n ansible.builtin.command: >\n kubectl --kubeconfig \/etc\/kubernetes\/admin.conf wait --for condition=established --timeout=90s\n crd\/installations.operator.tigera.io\n changed_when: false\n\n- name: Render the Calico Installation manifest\n ansible.builtin.template:\n src: calico-custom-resources.yaml.j2\n dest: \/root\/calico-custom-resources.yaml\n mode: "0644"\n\n- name: Apply the Calico Installation\n ansible.builtin.command: >\n kubectl --kubeconfig \/etc\/kubernetes\/admin.conf apply\n -f \/root\/calico-custom-resources.yaml\n register: calico_install\n changed_when: "'created' in calico_install.stdout or 'configured' in calico_install.stdout"\n\n- name: Generate a worker join command\n ansible.builtin.command: kubeadm token create --print-join-command\n register: join_cmd\n changed_when: false\n\n- name: Stash the join command for the worker play\n ansible.builtin.set_fact:\n kubeadm_join_command: "{{ join_cmd.stdout }}"\n\n- name: Fetch the admin kubeconfig to the Ansible controller\n ansible.builtin.fetch:\n src: \/etc\/kubernetes\/admin.conf\n dest: "{{ playbook_dir }}\/admin.conf"\n flat: true<\/code><\/pre>\n\n\nCalico ships as two pieces now. The operator CRDs go on first, then the operator itself, and only then does the Installation<\/code> resource make sense to the API. Apply them out of order and you get error: ... installations.operator.tigera.io not found<\/code>, which is exactly the trap the explicit CRD step and the kubectl wait<\/code> avoid. The Installation<\/code> manifest is a short template so the pod CIDR stays in one place:<\/p>\n\n\napiVersion: operator.tigera.io\/v1\nkind: Installation\nmetadata:\n name: default\nspec:\n calicoNetwork:\n ipPools:\n - name: default-ipv4-ippool\n blockSize: 26\n cidr: {{ pod_network_cidr }}\n encapsulation: VXLANCrossSubnet\n natOutgoing: Enabled\n nodeSelector: all()\n---\napiVersion: operator.tigera.io\/v1\nkind: APIServer\nmetadata:\n name: default\nspec: {}<\/code><\/pre>\n\n\nThe operator reconciles that Installation<\/code> into a running Calico deployment a few seconds after the API server comes up, and the pod CIDR matches the one kubeadm was handed.<\/p>\n\nJoin the workers<\/h2>\n\n
The worker role is short. It checks whether the node already belongs to a cluster, and if not, runs the join command the control-plane play stashed in a host fact. The stat<\/code> guard is what makes re-runs cheap: a node that already joined is skipped, not rejoined.<\/p>\n\n\n---\n- name: Check whether this node already joined the cluster\n ansible.builtin.stat:\n path: \/etc\/kubernetes\/kubelet.conf\n register: kubelet_conf\n\n- name: Join the node to the cluster\n ansible.builtin.command: "{{ hostvars[groups['control_plane'][0]]['kubeadm_join_command'] }}"\n when: not kubelet_conf.stat.exists\n changed_when: true<\/code><\/pre>\n\n\nThat is the whole worker role. The join runs at most once per node, which is what makes growing the cluster later a no-op for the nodes already in it.<\/p>\n\n
Run the bootstrap<\/h2>\n\n
One playbook ties the three roles together in order: prepare every node, build the control plane, join the workers, then wait for the whole cluster to report Ready.<\/p>\n\n\n
---\n- name: Prepare every node for Kubernetes\n hosts: k8s_cluster\n become: true\n roles:\n - common\n\n- name: Bring up the control plane\n hosts: control_plane\n become: true\n roles:\n - control_plane\n\n- name: Join the worker nodes\n hosts: workers\n become: true\n roles:\n - worker\n\n- name: Wait for all nodes to report Ready\n hosts: control_plane\n become: true\n tasks:\n - name: Wait for nodes to be Ready\n ansible.builtin.command: >\n kubectl --kubeconfig \/etc\/kubernetes\/admin.conf\n wait --for=condition=Ready nodes --all --timeout=180s\n register: nodes_ready\n changed_when: false\n\n - name: Show the cluster\n ansible.builtin.command: kubectl --kubeconfig \/etc\/kubernetes\/admin.conf get nodes -o wide\n register: get_nodes\n changed_when: false\n\n - name: Cluster nodes\n ansible.builtin.debug:\n var: get_nodes.stdout_lines<\/code><\/pre>\n\n\nRun it from the controller:<\/p>\n\n\n
ansible-playbook bootstrap.yml<\/code><\/pre>\n\n\nThe first run pulls the control-plane images and takes a few minutes; later runs are quick. When it finishes, every node is Ready and running the same Kubernetes version.<\/p>\n\n\n![\"Ansible](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-ansible-kubernetes-nodes-ready.png\" "\\"\\"")
<\/figure>\n\n\nThat is a working cluster, built from four blank Ubuntu installs, with no manual SSH into any node. If you would rather understand the kubeadm steps by hand before automating them, the kubeadm install walkthrough<\/a> covers the same flow one command at a time.<\/p>\n\nManage workloads with kubernetes.core<\/h2>\n\n
From here the job changes. The kubernetes.core.k8s<\/code> module sends manifests to the API server and reconciles them, the same way kubectl apply<\/code> does, except it lives in a playbook you can template, loop, and gate on conditions. The playbook below creates a namespace, a ConfigMap, a Secret, a three-replica Deployment that consumes both, and a NodePort Service, then waits until the Deployment reports Available.<\/p>\n\n\n---\n# Manage workloads on the cluster with the kubernetes.core collection.\n# Runs on the Ansible controller and talks to the API server over the kubeconfig.\n- name: Deploy a demo web app with Ansible\n hosts: localhost\n connection: local\n gather_facts: false\n vars:\n kubeconfig: "{{ lookup('env', 'HOME') }}\/ansible-k8s\/admin.conf"\n app_namespace: demo\n tasks:\n - name: Create the namespace\n kubernetes.core.k8s:\n kubeconfig: "{{ kubeconfig }}"\n api_version: v1\n kind: Namespace\n name: "{{ app_namespace }}"\n state: present\n\n - name: Publish the landing page as a ConfigMap\n kubernetes.core.k8s:\n kubeconfig: "{{ kubeconfig }}"\n state: present\n definition:\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: web-content\n namespace: "{{ app_namespace }}"\n data:\n index.html: |\n <h1>Deployed by Ansible<\/h1>\n <p>nginx on Kubernetes, managed end to end with kubernetes.core.<\/p>\n\n - name: Store an app secret\n kubernetes.core.k8s:\n kubeconfig: "{{ kubeconfig }}"\n state: present\n definition:\n apiVersion: v1\n kind: Secret\n metadata:\n name: web-secret\n namespace: "{{ app_namespace }}"\n type: Opaque\n stringData:\n api-key: rotate-me-in-vault\n\n - name: Deploy the web application\n kubernetes.core.k8s:\n kubeconfig: "{{ kubeconfig }}"\n state: present\n definition:\n apiVersion: apps\/v1\n kind: Deployment\n metadata:\n name: web\n namespace: "{{ app_namespace }}"\n labels:\n app: web\n spec:\n replicas: 3\n selector:\n matchLabels:\n app: web\n template:\n metadata:\n labels:\n app: web\n spec:\n containers:\n - name: nginx\n image: nginx:1.27\n ports:\n - containerPort: 80\n volumeMounts:\n - name: content\n mountPath: \/usr\/share\/nginx\/html\n env:\n - name: API_KEY\n valueFrom:\n secretKeyRef:\n name: web-secret\n key: api-key\n volumes:\n - name: content\n configMap:\n name: web-content\n\n - name: Expose the app on a NodePort\n kubernetes.core.k8s:\n kubeconfig: "{{ kubeconfig }}"\n state: present\n definition:\n apiVersion: v1\n kind: Service\n metadata:\n name: web\n namespace: "{{ app_namespace }}"\n spec:\n type: NodePort\n selector:\n app: web\n ports:\n - port: 80\n targetPort: 80\n nodePort: 30080\n\n - name: Wait until the deployment is Available\n kubernetes.core.k8s_info:\n kubeconfig: "{{ kubeconfig }}"\n api_version: apps\/v1\n kind: Deployment\n name: web\n namespace: "{{ app_namespace }}"\n wait: true\n wait_condition:\n type: Available\n status: "True"\n wait_timeout: 150\n\n - name: List the running pods\n kubernetes.core.k8s_info:\n kubeconfig: "{{ kubeconfig }}"\n kind: Pod\n namespace: "{{ app_namespace }}"\n label_selectors:\n - app=web\n register: web_pods\n\n - name: Show pod names and the nodes they landed on\n ansible.builtin.debug:\n msg: "{{ web_pods.resources | map(attribute='metadata.name') | zip(web_pods.resources | map(attribute='spec.nodeName')) | list }}"<\/code><\/pre>\n\n\nNotice it runs against localhost<\/code> with connection: local<\/code>. These tasks never SSH anywhere; they reach the API over the kubeconfig that bootstrap.yml<\/code> fetched to the controller. The kubernetes.core.k8s_info<\/code> calls at the end give you read access in the same language, with a wait_condition<\/code> that blocks until the rollout is genuinely ready instead of guessing with a sleep.<\/p>\n\n\nansible-playbook manage\/01-deploy-app.yml<\/code><\/pre>\n\n\nThe pods land across the workers, and the ConfigMap content is served on the NodePort.<\/p>\n\n\n![\"Ansible](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-ansible-kubernetes-deploy-app.png\" "\\"\\"")
<\/figure>\n\n\nBecause the module reconciles state, re-running the playbook after an edit changes only what differs. Bump replicas<\/code> to 5 and run it again and the three existing pods stay; Kubernetes adds two. That is the declarative model the kubernetes.core documentation<\/a> builds on, and it is why this beats a pile of shell calls to kubectl<\/code>.<\/p>\n\nInstall a Helm chart with Ansible<\/h2>\n\n
Most real clusters run Helm charts, and Ansible drives Helm without dropping to the shell. The kubernetes.core.helm<\/code> and helm_repository<\/code> modules add a repo and install or upgrade a release. metrics-server is a good first one: it is what kubectl top<\/code> needs, and a kubeadm cluster does not ship it.<\/p>\n\n\n---\n# Install a Helm chart with Ansible. metrics-server powers `kubectl top`.\n- name: Install metrics-server with Helm\n hosts: localhost\n connection: local\n gather_facts: false\n vars:\n kubeconfig: "{{ lookup('env', 'HOME') }}\/ansible-k8s\/admin.conf"\n tasks:\n - name: Add the metrics-server Helm repository\n kubernetes.core.helm_repository:\n name: metrics-server\n repo_url: https:\/\/kubernetes-sigs.github.io\/metrics-server\/\n\n - name: Install or upgrade the metrics-server release\n kubernetes.core.helm:\n kubeconfig: "{{ kubeconfig }}"\n name: metrics-server\n chart_ref: metrics-server\/metrics-server\n release_namespace: kube-system\n state: present\n update_repo_cache: true\n # kubeadm issues self-signed kubelet certs, so skip TLS verification to it.\n values:\n args:\n - --kubelet-insecure-tls\n\n - name: Wait for the metrics-server rollout\n kubernetes.core.k8s_info:\n kubeconfig: "{{ kubeconfig }}"\n api_version: apps\/v1\n kind: Deployment\n name: metrics-server\n namespace: kube-system\n wait: true\n wait_condition:\n type: Available\n status: "True"\n wait_timeout: 150<\/code><\/pre>\n\n\nThe --kubelet-insecure-tls<\/code> argument is the gotcha. kubeadm gives each kubelet a self-signed serving certificate, and metrics-server refuses to scrape it unless you tell it to skip that verification. Without the flag the pod runs but kubectl top<\/code> answers “Metrics API not available” forever. Install it, give it a scrape cycle, and node metrics appear.<\/p>\n\n\nansible-playbook manage\/02-helm-metrics-server.yml\nkubectl top nodes<\/code><\/pre>\n\n\nNode CPU and memory now report through the metrics API:<\/p>\n\n\n![\"Ansible](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-ansible-kubernetes-helm-metrics-server.png\" "\\"\\"")
<\/figure>\n\n\nThat is the case for running Helm through Ansible rather than by hand: the release is declared in a playbook you can re-run, template, and keep in version control next to everything else.<\/p>\n\n
Drain a node and roll a deployment<\/h2>\n\n
Patching a node means moving its pods elsewhere first. kubernetes.core.k8s_drain<\/code> cordons and drains in one task, and the matching uncordon<\/code> brings the node back. The playbook drains a worker, confirms it is unschedulable, returns it to service, then triggers a rolling restart of the web Deployment by stamping a fresh annotation on the pod template.<\/p>\n\n\n---\n# Day-2 operations: drain a node for maintenance, bring it back, roll a deployment.\n- name: Node maintenance and a rolling restart with Ansible\n hosts: localhost\n connection: local\n gather_facts: false\n vars:\n kubeconfig: "{{ lookup('env', 'HOME') }}\/ansible-k8s\/admin.conf"\n target_node: k8s-w2\n app_namespace: demo\n tasks:\n - name: Cordon and drain the node\n kubernetes.core.k8s_drain:\n kubeconfig: "{{ kubeconfig }}"\n name: "{{ target_node }}"\n state: drain\n delete_options:\n ignore_daemonsets: true\n delete_emptydir_data: true\n terminate_grace_period: 30\n wait_timeout: 120\n\n - name: Confirm the node is unschedulable\n kubernetes.core.k8s_info:\n kubeconfig: "{{ kubeconfig }}"\n kind: Node\n name: "{{ target_node }}"\n register: drained_node\n\n - name: Node scheduling state\n ansible.builtin.debug:\n msg: "{{ target_node }} unschedulable = {{ drained_node.resources[0].spec.unschedulable | default(false) }}"\n\n # Real maintenance (kernel patch, reboot) would happen here.\n\n - name: Bring the node back into the scheduler\n kubernetes.core.k8s_drain:\n kubeconfig: "{{ kubeconfig }}"\n name: "{{ target_node }}"\n state: uncordon\n\n - name: Trigger a rolling restart of the web deployment\n kubernetes.core.k8s:\n kubeconfig: "{{ kubeconfig }}"\n state: patched\n kind: Deployment\n name: web\n namespace: "{{ app_namespace }}"\n definition:\n spec:\n template:\n metadata:\n annotations:\n ansible.computingforgeeks.com\/restartedAt: "{{ now(utc=true).isoformat() }}"\n\n - name: Wait for the rollout to finish\n kubernetes.core.k8s_info:\n kubeconfig: "{{ kubeconfig }}"\n api_version: apps\/v1\n kind: Deployment\n name: web\n namespace: "{{ app_namespace }}"\n wait: true\n wait_condition:\n type: Available\n status: "True"\n wait_timeout: 150<\/code><\/pre>\n\n\nWrap the drain and uncordon around a real maintenance task and you have a repeatable patch window: drain, reboot the node with the reboot<\/code> module, wait for it, uncordon. The rolling-restart trick at the end is the same one kubectl rollout restart<\/code> uses under the surface, expressed as a patch.<\/p>\n\n\nansible-playbook manage\/03-day2-operations.yml<\/code><\/pre>\n\n\nThe node leaves and rejoins the scheduler, and the Deployment rolls one pod at a time:<\/p>\n\n\n![\"Ansible](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-ansible-kubernetes-day2-drain-node.png\" "\\"\\"")
<\/figure>\n\n\nThe k8s_drain<\/code> module handles the eviction along with the daemonset and emptydir edge cases that a hand-rolled wrapper around kubectl drain<\/code> usually forgets.<\/p>\n\nAdd a worker node<\/h2>\n\n
This is where the idempotent roles pay off. To grow the cluster, add the new node under [workers]<\/code> in the inventory and run the same bootstrap playbook. Nothing else changes.<\/p>\n\n\n[workers]\nk8s-w1 ansible_host=192.168.1.169\nk8s-w2 ansible_host=192.168.1.170\nk8s-w3 ansible_host=192.168.1.157<\/code><\/pre>\n\n\nThen re-run the bootstrap, unchanged:<\/p>\n\n\n
ansible-playbook bootstrap.yml<\/code><\/pre>\n\n\nThe existing nodes report changed=0<\/code> because their state already matches. Only the new node runs the prep tasks and the join, and it is Ready in under a minute.<\/p>\n\n\n![\"Ansible](\"https:\/\/computingforgeeks.com\/wp-content\/uploads\/2026\/06\/wm-ansible-kubernetes-add-worker-node.png\" "\\"\\"")
<\/figure>\n\n\nThe same loop scales the other way for cloud fleets: instead of editing the inventory by hand, pull the node list from your provider with dynamic inventory<\/a> and let the count drive itself.<\/p>\n\nTroubleshooting<\/h2>\n\nFailed to import the required Python library (kubernetes)<\/h3>\n\n
The kubernetes.core<\/code> modules cannot find the Python client. It is almost always installed into the wrong environment. If you installed Ansible with pipx, run pipx inject ansible kubernetes<\/code> so the client lands in Ansible’s venv. With a system Ansible, install python3-kubernetes<\/code> from apt instead.<\/p>\n\nerror: … installations.operator.tigera.io not found<\/h3>\n\n
Calico’s Installation<\/code> resource was applied before its CRD existed. Recent Calico splits the CRDs into operator-crds.yaml<\/code>, which has to go on before tigera-operator.yaml<\/code>. The role applies them in that order and then runs kubectl wait --for condition=established<\/code> on the CRD, so the race cannot happen.<\/p>\n\nPods stuck in ContainerCreating, nodes never Ready<\/h3>\n\n
Two usual causes. Either containerd is still on the cgroupfs driver (check that SystemdCgroup = true<\/code> is set in \/etc\/containerd\/config.toml<\/code> and containerd was restarted), or the pod CIDR overlaps your LAN and the CNI cannot route. Confirm the value in group_vars\/all.yml<\/code> is a range your network does not use.<\/p>\n\nkubectl top says “Metrics API not available”<\/h3>\n\n
metrics-server is running but cannot scrape the kubelets. On a kubeadm cluster it needs --kubelet-insecure-tls<\/code>, set through Helm values as shown above. Give it thirty seconds after the rollout for the first scrape before deciding it is broken.<\/p>\n\nTake it to production<\/h2>\n\n
The cluster here has one control-plane node, which is fine for a lab and wrong for anything you depend on. The same roles extend in a few clear steps. Run three control-plane nodes behind a load balancer and pass --control-plane-endpoint<\/code> to kubeadm init<\/code> so the API has a stable address to fail over to. Keep the Kubernetes minor pinned in group_vars<\/code> and bump it deliberately, one minor at a time, rather than letting apt decide. Most of all, stop storing Secrets as plain text in a playbook: the stringData<\/code> field in the deploy example is readable to anyone with the repo, so move those values behind Ansible Vault<\/a> and reference them as variables. The full set of roles and playbooks, ready to clone, lives in the companion repository<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"Ansible and Kubernetes meet at two points, and they pull in different directions. The first is provisioning: turning a pile of fresh Ubuntu machines into a working cluster. kubeadm assembles the cluster, but something has to disable swap, load kernel modules, install containerd, lay down the package repo, and run kubeadm in the right order … Read more<\/a><\/p>\n","protected":false},"author":3,"featured_media":168540,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[606,329,316,317],"tags":[314,212,218,318],"cfg_series":[39825],"class_list":["post-168411","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ansible","category-automation","category-containers","category-kubernetes","tag-ansible","tag-automation","tag-containers","tag-kubernetes","cfg_series-ansible-mastery"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/168411","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=168411"}],"version-history":[{"count":2,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/168411\/revisions"}],"predecessor-version":[{"id":168413,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/168411\/revisions\/168413"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/168540"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=168411"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=168411"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=168411"},{"taxonomy":"cfg_series","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/cfg_series?post=168411"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}