Challenge Easy

Restore a Stalled Deployment

Clavin June
by  Clavin June · on
KubernetesNetworking
A focused 15–25 minute Multus troubleshooting challenge: investigate stalled pods and restore the application's expected connectivity.
#multus#cni
Important

AI assistance, personal use, and safety notice

This challenge was created with Hermes Agent and GTP-6-Astra Ultra for personal learning and experimentation. It is an AI-assisted learning resource, not official documentation or production guidance.

It may contain mistakes, outdated instructions, or unsafe assumptions. Read the challenge carefully and independently review every command and manifest before running it. Use an isolated, disposable lab, not production or a system you cannot afford to break. Passing the included checks is not a security audit or a guarantee that the instructions are safe in another environment.

I provide this material as is, for educational purposes only, with no warranties or guarantees of accuracy, completeness, security, safety, or suitability for your needs. Use your own judgment and proceed at your own risk. You are responsible for deciding what to run in your environment and for the consequences.

Incident

The apps Deployment in namespace multus is stalled: its pods are not becoming Ready. Your task is to investigate the live cluster, identify the cause, and restore the workload. Do not assume the displayed pod status is a diagnosis.

Allow 15–25 minutes. This is a troubleshooting companion to section 6 of Multus CNI From Scratch, not an official certification assessment.

Environment and scope

Work on dev-machine once initialization finishes. Select flannel and containerd if asked when starting. Kubernetes, Flannel, Multus v4.3.1, and the application's existing secondary NetworkAttachmentDefinition are already provided. The workload is scheduled on node-01.

Use only this disposable playground. Nothing here requires touching your own server. Keep your repair limited to the application's Deployment; replacing its pods through a normal rollout is allowed.

Required end state

  • Deployment multus/apps has two Ready and available replicas, with its current rollout fully observed and complete.
  • Preserve its name, selector, node placement, and single nicolaka/netshoot:v0.14 tools container. Keep a long-running command such as sleep infinity.
  • Both Deployment-managed pods use the existing secondary network, with distinct real net1 addresses in 192.168.50.0/24. Multus network-status must agree with the actual interfaces.
  • Secondary communication works in both directions through net1.
  • The primary pod addresses remain on eth0, exactly one IPv4 default route remains through eth0, primary pod-to-pod traffic still works, and Kubernetes service DNS resolves from both pods.
  • The repair must survive replacement pods. Preserve the existing NAD and its CNI configuration; do not rename, replace, edit, or add NADs, and do not modify Flannel, Multus, or node CNI files. Do not replace the Deployment with standalone pods or bypass checks with scaling or host networking.

The check is read-only and never repairs the workload for you. Use the cluster's own evidence to determine what needs changing.

Stop the playground when finished. Start a fresh run to repeat the investigation.

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge multus-restore-a-stalled-deployment-a39969a4

This will create a local copy of the challenge content in a directory named multus-restore-a-stalled-deployment-a39969a4. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge multus-restore-a-stalled-deployment-a39969a4

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge