Create a Multus Network and Attach Two Pods
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.
Your goal
Create a secondary network and attach two pods without changing their ordinary Kubernetes network. This is a 20–30 minute companion to sections 3–4 of Multus CNI From Scratch. It is independent personal CKNE practice, not an official certification assessment.
Starting state: Kubernetes, containerd, Flannel, and Multus v4.3.1 are ready. The multus namespace exists, but the blue-lan NAD and pods blue and green do not. Multus installation is provided, not part of your task. Choose flannel and containerd if the start dialog offers choices. Work on dev-machine after initialization completes.
Use only this disposable playground. The provided Multus quickstart installs privileged cluster-wide components; it is not production guidance. Nothing here requires touching your own server.
1. Define the network
In namespace multus, create a NetworkAttachmentDefinition named blue-lan with this CNI configuration:
| Setting | Required value |
|---|---|
| CNI version | 0.3.1 |
| CNI network name | blue-lan |
| Plugin | bridge |
| Linux bridge | br-blue |
| IPAM | host-local |
| Single IPv4 subnet | 192.168.50.0/24 |
Do not enable gateway mode, a secondary default gateway, or IP masquerading. Do not add a default route to the secondary IPAM configuration. Omitted or false gateway/masquerading flags are accepted; the single subnet may use ranges or subnet notation.
2. Attach two pods
Create pods blue and green in namespace multus. Both must:
- Run on node-01 using the ordinary pod network (not host networking).
- Have one container using nicolaka/netshoot:v0.14, with a long-running command such as sleep infinity so it stays available for inspection.
- Request the NAD at pod creation using annotation key k8s.v1.cni.cncf.io/networks and the exact shorthand value blue-lan. Alternative annotation encodings are valid in Multus but intentionally outside this exercise's checker contract.
- Become Ready with a real net1 interface and distinct addresses from 192.168.50.0/24. The Multus network-status annotation must agree with the actual interface.
- Retain their normal pod IP on eth0 and exactly one IPv4 default route, through eth0.
Success criteria
Both pods must be able to ping the other's actual net1 address through net1, in both directions. Kubernetes service DNS (kubernetes.default.svc.cluster.local) must still resolve correctly from both pods. The final check rechecks the NAD and attachments as well as these network paths; checks inspect state and never create or repair your resources.
Optional: a definition is not an attachment
A NAD stores a JSON CNI configuration. Multus reads a pod's requested networks when its sandbox is created; creating a NAD alone does not add interfaces to existing pods.
Optional: inspect requests and results separately
Compare the pod's networks and network-status annotations with its real interfaces and routes. Discover the peer's current address instead of assuming a particular allocation. If you created a pod before adding its annotation, recreate that disposable pod to exercise fresh CNI setup.
Both pods deliberately share one node: a Linux bridge is node-local and host-local IPAM does not coordinate allocations across nodes. Cross-node secondary transport, network-policy isolation, Multus installation, and typo-repair exercises are outside this challenge. Stop the playground when finished; start a fresh run for another attempt.