Forem: Anjali Mishra

My Kubernetes SIGs Contribution: Updating Hydrophone’s e2e Test Infrastructure (K8s v1.34.0 + kind v0.30.0)

Anjali Mishra — Sun, 30 Nov 2025 15:33:44 +0000

Recently, I contributed a PR to kubernetes-sigs/hydrophone, a CNCF project used for Kubernetes end-to-end testing.
The goal was simple but impactful:

👉 Update the Kubernetes and kind versions used in the e2e test environment.

This blog explains:

Why this PR was needed

What changes I made

How the review/merge process works in CNCF orgs

What I learned as a DevOps & Cloud Engineering student

Tips for beginners contributing to Kubernetes SIGs

🌟 What is Hydrophone?

Hydrophone is a lightweight test runner used in Kubernetes SIG-Testing. It defines and executes:

e2e workflows

Conformance test suites

Validation checks for Kubernetes clusters

Whenever Kubernetes ships a new version, Hydrophone helps validate:

✔ API behaviour
✔ Conformance guarantees
✔ Compatibility
✔ Cluster setup reliability

Keeping Hydrophone’s e2e environment updated is critical.

🎯 What Problem Was I Solving?

The script hack/run-e2e.sh was using older versions:

K8S_VERSION=v1.29.2
KIND_VERSION=v0.22.0

But newer stable releases were available:

Kubernetes: v1.34.0

kind: v0.30.0

Using outdated versions leads to:

❌ Mismatches with TestGrid
❌ Difficulty reproducing failures locally
❌ Unsupported APIs
❌ Inconsistent e2e results

So my PR updated the version variables.

🛠 My Contribution (PR #283)

Updated lines:

K8S_VERSION=${K8S_VERSION:-v1.34.0}
KIND_VERSION=${KIND_VERSION:-v0.30.0}

After updating, I:

✔ Verified compatibility
✔ Ran local kind clusters
✔ Ensured e2e tests passed
✔ Wrote a clean PR description
✔ Monitored TestGrid after merge

A small but meaningful contribution that keeps Hydrophone aligned with the latest Kubernetes ecosystem.

🔄 The Review & Merge Journey

This was the exciting part!

k8s-ci-robot responded

It waited for an org member to approve testing.

/ok-to-test

A maintainer triggered the CI pipeline.

/lgtm + /approve

Reviewers validated & approved the PR.

TestGrid Monitoring

I tracked these dashboards:

https://testgrid.k8s.io/sig-testing-misc#hydrophone-e2e-check

https://testgrid.k8s.io/sig-testing-misc#hydrophone-conformance-check

All tests were green 💚 after the version bump.

🤝 What I Learned from This Contribution
🧩 1. How SIG workflows operate

Seeing /ok-to-test, /lgtm, /approve in action was a valuable experience.

🛠 2. Importance of updating test infra

Even a tiny bump improves CI stability.

📊 3. Monitoring TestGrid

Understanding periodic jobs is essential for DevOps engineers.

🔍 4. Writing clear PRs

Good descriptions = faster reviews.

💬 5. Communication with maintainers

Acknowledging feedback + iterating builds trust.

🧪 Why DevOps Engineers Should Contribute to CNCF Projects

Contributing helped me grow in:

Infrastructure as Code

CI/CD workflows

Kubernetes internals

Open-source collaboration

Real-world debugging

Bash scripting

Working with global maintainers

If you're a DevOps/cloud engineer, CNCF contributions give you:

✔ Visibility
✔ Credibility
✔ Hands-on skills
✔ Confidence

🧭 Tips for Beginners Who Want to Contribute to Kubernetes
1️⃣ Start with “good first issue”

Repos under kubernetes-sigs have beginner-friendly issues.

2️⃣ Reproduce issues locally

Use kind or minikube.

3️⃣ Keep PRs small

Small PRs get merged quickly.

4️⃣ Join Kubernetes Slack

SIG-Testing and SIG-Contributor Experience are great places to start.

5️⃣ Write clear commit messages

It helps maintainers understand the changes.

6️⃣ Don’t hesitate to ask

The community is very friendly ✨

📌 Final Thoughts

This PR made Hydrophone’s test environment more modern, stable, and aligned with Kubernetes 1.34.

Contributing to CNCF projects has been an amazing journey for me as a DevOps & Cloud student — and I hope this blog inspires others to start their open-source journey too!

If you want to contribute to Kubernetes, feel free to reach out — happy to help 💬🙂

🚀How My Kubernetes KIND Contribution Got Merged: A Beginner’s Journey Into Real Open Source

Anjali Mishra — Sat, 15 Nov 2025 14:52:33 +0000

My First Kubernetes Contribution: A Journey of Mentorship, Reviews, CNCF CLA & My PR Getting Merged

Contributing to open source was always a dream…
but contributing to a Kubernetes SIGs repository felt like a dream that was too big.

Kubernetes is massive.
Its contributors are experts.
Its ecosystem is huge.

So when I created my first PR to kubernetes-sigs/kind, I didn’t just write a few lines of documentation —
I crossed a personal milestone that changed my confidence forever.

Let me take you through the journey —
of learning, mentorship, mistakes, corrections, CNCF processes, approvals, and growth.

🌱 The Start — A Small Idea, A Big Step

While reading KIND’s Quick Start docs, I noticed something simple:

👉 There was no example for loading multiple Docker images in a single command.

Beginners do this all the time.
Yet the docs only showed single-image examples.

So I decided to contribute this:

kind load docker-image my-app:latest my-db:latest my-cache:latest

A small, beginner-friendly improvement —
but a perfect entry point into the Kubernetes ecosystem.

🧪 Step 1: Passing the CNCF CLA — My First Real Gate

Before ANY Kubernetes PR can be tested or reviewed, contributors must pass:

✔ The CNCF Contributor License Agreement (CLA)

This is a legally required agreement proving:

the code is original

you allow CNCF to use it

there are no license conflicts

When I opened my PR, I saw the bot:

💬 “CLA not signed”

This was my first major step.

I opened the link, authenticated with GitHub, verified details, and signed it.

And then the bot updated:

💚 CLA Signed — You’re good to go!

The moment that label turned green, I felt like:
Yes, I’ve officially stepped into the CNCF ecosystem.

🤖 Step 2: Bots, Labels & The “ok-to-test” Workflow

Kubernetes has an amazing automated system.

Immediately after my PR:

@k8s-ci-robot welcomed me

added labels

checked CLA

explained commands

asked a maintainer to approve /ok-to-test

Before “ok-to-test,” tests aren’t triggered.

Once a maintainer reviewed the PR and said:

/ok-to-test

The CI pipelines finally started running.

Watching those green checks pass felt surprisingly exciting 😄

🌟 Step 3: The Reviewers Who Helped Me Grow

This PR introduced me to three amazing maintainers:

⭐ @stmcginnis
⭐ @bentheelder
⭐ @aojea

And each one helped me in different ways.

🧑‍🏫 The Mentor of My PR — @stmcginnis

If this blog had a hero, it would be @stmcginnis.

He didn’t just review my PR —
he mentored me throughout the entire process.

What he taught me:
✔ What was wrong

He spotted issues I completely missed:

wrong indentation

missing backticks

extra blank lines

duplicate sections appearing at the bottom

formatting not matching KIND’s documentation style

✔ What was right

He appreciated the value of the example and encouraged me to continue.

✔ How to fix things

He never said “This is wrong.”
He always explained:

📌 Why it's wrong
📌 How to correct it
📌 What good documentation looks like
📌 How to apply changes cleanly

✔ The biggest lesson: how to amend a commit properly

When I struggled with squashing commits, he gave me a magic command:

git add .
git commit --amend
git push -f

This single message saved me HOURS of confusion.

His tone was always:

patient

kind

respectful

supportive

He turned a scary Kubernetes contribution into a smooth learning experience.

I am truly grateful for his mentorship. 🙏

🧩 The Other Maintainers Who Supported Me
⭐ @bentheelder

Co-maintainer of KIND — he ensured the changes fit the project’s design and documentation structure.

⭐ @aojea

He helped me clean the commit history and reminded me to avoid unrelated changes.
His advice about keeping the PR focused improved my understanding of professional open-source collaboration.

Each of them guided me toward making my contribution clean, accurate, and merge-ready.

This was REAL open-source collaboration — and I felt privileged to experience it.

🔄 Step 4: Iterations, Fixes & Growth

My PR didn’t get accepted immediately.

Not after one review.
Not after two.
Not after five.

Every time I fixed one thing, the reviewers found another improvement.
And every time I fixed something new, I learned something new.

I made mistakes like:

messing up formatting during squash

duplicating sections accidentally

incorrect markdown spacing

missing newline after headers

breaking layout with unintended edits

But the maintainers stayed patient.

They guided me with:

✔ clear comments
✔ constructive feedback
✔ friendly tone
✔ encouragement to continue

This is the beauty of open source:
Mistakes are not failures — they are lessons.

🎉 Step 5: The Final Approval — /lgtm & /approve

After all the fixes, all the formatting corrections, all the rebasing and amending…

I finally saw the most satisfying comment:

/lgtm

Followed by:

/approve

And then the bot said:

💚 This PR is APPROVED
💚 Merged successfully

That green “Merged” badge still feels special.

I had officially contributed to a Kubernetes SIGs repository.

🌈 What This Journey Taught Me
🌟 Mentorship matters

Good reviewers like @stmcginnis don’t just correct you — they grow you.

🌟 Open source is teamwork

It’s about patience, communication, and collaboration.

🌟 Small contributions matter

Even a one-line doc example can help thousands of developers.

🌟 Communication is a skill

Responding professionally, asking doubts, and following up politely matters.

🌟 CNCF ecosystem welcomes beginners

The process is structured, educational, and encouraging.

💛 My Heartfelt Thanks
To @stmcginnis

Your mentorship, explanations, and kindness shaped my entire journey.
Thank you for helping me learn the right way.

To @bentheelder

Thank you for reviewing and ensuring the doc improvements matched KIND’s standards.

To @aojea

Thank you for guiding me on squashing and keeping the PR clean.

To the Kubernetes SIGs community

Thank you for creating an environment where beginners can grow.

🔮 What's Next for Me

This contribution gave me:

✨ Confidence
✨ Technical clarity
✨ Experience with CNCF workflows
✨ Understanding of PR reviews
✨ Skills for real-world collaboration

Now I’m working toward:

more contributions to CNCF projects

understanding Go + Kubernetes internals

preparing for GSoC 2026

helping beginners get into open source

This is just the beginning of my open-source journey.

🌸 Final Words to Beginners

If you want to contribute but feel scared or unprepared:

Just start.

Start with one small issue.
One doc improvement.
One PR.
One review.

Open source isn’t about perfection —
it’s about participation and learning.

If I can contribute to Kubernetes,
you absolutely can too.

💌 Connect With Me

If you need help finding your first issue or starting your OSS journey:

📌 GitHub: https://github.com/AnjaliMishra1st

📌 LinkedIn: https://www.linkedin.com/in/anjali-mishra-212536298/

📌 Email: mishrasitu88@gmail.com

I’m always happy to help ❤️

My First Open Source journey

Anjali Mishra — Thu, 13 Nov 2025 18:23:39 +0000

🌱 Introduction — How It All Started

Every open-source journey begins with a small step.

Mine began with a mixture of excitement, nervousness, and curiosity when I participated in GirlScript Summer of Code (GSSoC).

I always wanted to contribute to open source, but I didn’t know where to begin:

What project should I pick?
What if I break something?
What if maintainers ignore me?
Will I understand the codebase?

Everything changed when I joined Techtonica’s curriculum repository and met someone who transformed my confidence —

my mentor Daaimah.

🌟 Finding the Right Issue

I came across an issue titled:

“Create topic outline with interactive walkthrough and visuals for Minimum Spanning Tree (Prim's and Kruskal's Algorithm).”

It wasn’t a tiny fix; it required:

✔ Creating a full topic outline

✔ Adding algorithm visuals

✔ Adding time/space complexity tables

✔ Writing clear explanations

✔ Matching Techtonica’s curriculum style

✔ Making it beginner-friendly

This was a real contribution — not a small typo fix.

So, I decided to take the first step.

❤️ Meeting My First Open-Source Mentor

When I submitted my first PR, I was nervous.

But instead of criticism, I received the kindest and most patient guidance from my mentor @daaimah123.

She didn’t just review my PR —

she taught me how to contribute professionally.

Here’s what she taught me:

🌼 How to structure documentation

Not just writing — but teaching.

🌼 How to respond to reviews professionally

Acknowledge feedback
Explain what you changed
Reference commit hashes
Mark conversations as resolved

🌼 How to improve formatting

Headings, spacing, tables, visuals — everything.

🌼 How to iterate without giving up

She reviewed multiple times, with:

Patience
Encouragement
Examples
Detailed instructions

She even scheduled pair programming Zoom sessions, recorded videos explaining mistakes, and guided me line by line.

She wasn’t just a reviewer —

she was my first open-source teacher.

💪 The Hard Part — Iterating Again and Again

My PR did not get accepted on the first try.

Or the second.

Or the third.

I made many mistakes:

Missing formatting
Incorrect markdown
Broken links
Inconsistent structure
Missing complexity sections
Unclear visuals

Each time I pushed a commit, she guided me again.

Her kindness kept me going.

Her patience made me feel safe to learn.

Her feedback helped me grow.

I improved my:

technical thinking
documentation structure
algorithm understanding
communication skills
attention to detail

Slowly, the PR became cleaner.

More structured.

More educational.

And then…

🎉 The Moment Everything Changed — PR Merged!

On August 19, my pull request was finally approved and merged.

Seeing the green Merged badge gave me:

✨ Confidence

✨ Motivation

✨ Pride

✨ A sense of belonging

✨ Belief in myself

My mentor even left a supportive congratulatory message, appreciating my persistence and learning.

That day, I felt like I had truly stepped into open source.

🌈 What I Learned from This Contribution

This journey taught me:

⭐ Open source is not just coding

It is learning, collaboration, and kindness.

⭐ A great mentor changes everything

Good guidance builds confidence.

⭐ Improvement happens through feedback

Not from doing everything perfectly the first time.

⭐ Communication is as important as code

Clear PR messages, responses, and iterations matter.

⭐ Willingness > Experience

Beginners grow fast when they stay open to feedback.

🤝 A Heartfelt Thank You to My Mentor

To @daaimah123 —

thank you for your patience, clarity, kindness, and support.

Thank you for:

your detailed explanations
your constructive feedback
your pair programming sessions
your encouragement
your belief in my growth

You made my first contribution meaningful and memorable.

🌟 What’s Next for Me — My Path Toward GSoC 2026

This contribution gave me a strong foundation.

Now I’m preparing for Google Summer of Code (GSoC) 2026 with:

✨ More confidence

✨ More discipline

✨ More technical depth

✨ More open-source skills

I now understand:

documentation structure
collaboration
communication
iteration
review process

This is just the beginning — not the end.

✨ Final Thoughts

If you're a beginner:

👉 Start small

👉 Don’t fear mistakes

👉 Ask questions

👉 Accept feedback

👉 Keep improving

👉 Find a mentor

Your first contribution can change your journey — just like mine did.

🧡 Connect with Me

GitHub: https://github.com/AnjaliMishra1st

LinkedIn: https://www.linkedin.com/in/anjali-mishra-212536298/

Email: mishrasitu88@gmail.com

If you want help starting open source, feel free to message me.

Thank you for reading ❤️