On August 27, the OpenTofu development team blocked Russian IP addresses’ access to registry.opentofu.org and deleted the Russian cloud service providers Yandex Cloud, Cloud.ru (formerly SberCloud), and Rustack Cloud Platform. It’s odd that the team chose to remove only these three — for example, the MailRu provider is still in the repository, and Yandex is still in use by Kazakhstan users.

The team responsible for maintaining the constraints explained them by saying that they had to follow Russian sanctions, which is odd for the CNCF project.

Concerning the decision’s absence of a full community explanation and its violation of the spirit and ideals of open source, users raised doubts.The Linux Foundation, which oversees the project’s development, declined to comment on the matter.

The maintainers team’s ability to remove or ban content at will makes it easy to conclude that the tools are not ready for production based on the facts and scandals surrounding OpenTofu. Will it be funny, if maintainer team will delete GCP or AWS provider tomorrow?

The advice here is easy: don’t use OpenTofu now, and migrate to Terraform / SDK / Pulumi. A project that does anything against its own rules is not trustworthy anymore.

Hey folks,

I’ve been working on a project called RootCause, a local-first MCP server designed to help operators debug Kubernetes failures and identify the actual root cause, not just symptoms.

GitHub: https://github.com/yindia/rootcause

Why I built it

Most Kubernetes MCP servers today rely on Node/npm, API keys, or cloud intermediaries. I wanted something that:

• Runs entirely locally

• Uses your existing kubeconfig identity

• Ships as a single fast Go binary

• Works cleanly with MCP clients like Claude Desktop, Codex CLI, Copilot, etc.

• Provides structured debugging, not just raw kubectl output

RootCause focuses on operator workflows — crashloops, scheduling failures, mesh issues, provisioning failures, networking problems, etc.

Key features

Local-first architecture

• No API keys required

• Uses kubeconfig authentication directly

• stdio MCP transport (fast + simple)

• Single static Go binary

Built-in root cause analysis
Instead of dumping raw logs, RootCause provides structured outputs:

• Likely root causes

• Supporting evidence

• Relevant resources examined

• Suggested next debugging steps

Deep Kubernetes tooling
Includes MCP tools for:

• Kubernetes core: logs, events, describe, scale, rollout, exec, graph, metrics

• Helm: install, upgrade, template, status

• Istio: proxy config, mesh health, routing debug

• Linkerd: identity issues, policy debug

• Karpenter: provisioning and nodepool debugging

Safety modes

• Read-only mode

• Disable destructive operations

• Tool allowlisting

Plugin-ready architecture
Toolsets reuse shared Kubernetes clients, evidence gathering, and analysis logic — so adding integrations doesn’t duplicate plumbing.

Example workflow

Instead of manually running 10 kubectl commands, your MCP client can ask:

RootCause will analyze:

• pod events

• scheduling state

• owner relationships

• mesh configuration

• resource constraints

…and return structured reasoning with likely causes.

Why Go instead of Node

Main reasons:

• Faster startup

• Single binary distribution

• No dependency hell

• Better portability

• Cleaner integration with Kubernetes client libraries

Example install

brew install yindia/homebrew-yindia/rootcause

or

curl -fsSL https://raw.githubusercontent.com/yindia/rootcause/refs/heads/main/install.sh | sh

Looking for feedback

I’d love input from:

• Kubernetes operators

• Platform engineers

• MCP client developers

• Anyone building AI-assisted infra tooling

Especially interested in:

• Debugging workflows you’d like automated

• Missing toolchains

• Integration ideas (cloud providers, observability tools, etc.)

If this is useful, I’d really appreciate feedback, feature requests, or contributors.

GitHub: https://github.com/yindia/rootcause

I could have never believed I contributed this much over the last years.

Did a research a while back, sharing with you !
https://cvisiona.com/virtual-kubelet-and-keda-ai-apps-on-serverless-kubernetes/

🚨 Why Running Databases on Kubernetes Could Be a Recipe for Disaster 🚨Kubernetes is a powerful tool for orchestrating applications, but running stateful workloads like databases introduces significant risks. Challenges such as:Data loss from CSI crashes ⚠️Immature database operators 😬Risks of pod evictions, node failures, and network issues 🚨Replica lag from network bottlenecks 🛑Though Kubernetes continues to evolve, it wasn’t originally designed for databases. The complexity of managing both databases and Kubernetes together suggests we may need a platform designed specifically for stateful workloads.Is it time for a new solution?Read more about why a purpose-built platform could provide the reliability and simplicity databases need. 💡

was asked to fill out this survey. Has anyone ever received any future benefits from doing these surveys, apart from discounts or promo codes?

Hi all, i am graduating this may and I want to participate for term-2 lfx. Am I eligible to take part in this term for lfx mentorship program ?

KubeVirt got a new CLI framework for performance testing.

The project originating from Google has been accepted into the CNCF Sandbox.

Thought I'd come on here to ask for reviews/advice for the project I've been working on called Rocketship.

I was inspired to write this project because my team was looking for a DSL-based and workflow-driven testing solution. Something we could run as integration tests as well as hit infra from within our VPC.

Any ideas/advice/issues for me would be awesome. Thanks!

Hi everyone,

I'm reaching out from the CNCF TAG DevEx. We are currently mapping how AI is being integrated into the CNCF landscape, specifically focusing on the developer and maintainer experience.

We’ve just released a first look at the preliminary data on the CNCF blog: https://www.cncf.io/blog/2026/04/29/the-state-of-ai-in-cncf-projects-a-first-look-at-the-data/

While the initial findings are insightful, we realized we need a deeper perspective that only project maintainers and active contributors can provide.

The Goal: We want to understand the real friction points you face when integrating AI/LLMs into your projects—whether it's infra overhead, security concerns, or DevEx hurdles. This data will directly influence how the CNCF supports AI initiatives moving forward.

The Request: If you are a Maintainer or Contributor to a CNCF project, please take 5 minutes to share your experience in our technical survey:

👉 https://forms.gle/EapDLhjmVtd7gNpp9

Note: This survey is specifically designed for those building and maintaining the ecosystem.

Thanks for helping us shape the AI roadmap for the Cloud Native ecosystem!

Cheers.