Deprecation and future removal of CRDs

[phillebaba]

For a while the community has reported issues with infinite reconcile loops of resources causing significant CPU usage and duplicate resource creation. After studying the issues we determined that a refactor of the operator was necessary to address these issues and ensure a stable experience in the future.

Over the last two months we have introduced new CRDs meant to replace the "old" CRDs with an NB prefix. This was done to avoid breaking existing use cases and enabling the most amount of flexibility during the refactor. Now that work is complete and we have a release where both the new and old CRDs are reconciled.

I can it can be frustrating to move to using new CRDs and we would not have done this if it was not absolutely necessary. It is important for the end users of the NetBird operator to start migrating over to the new resources. We will keep the code for the old ones untouched for the time being to allow for a migration period. During this time we will focus our time on bug fixes and feature development on the new CRDs. Once we feel like everyone has had ample time to migrate we will remove all code related to the following CRDs.

• NBGroups
• NBResources
• NBPolicies
• NBRoutingPeers
• NBSetupKey

Thank you for your understanding, and we are looking forward to further develop the operator to improve the stability and expand on the features in the futre.

[hebertdougl]

Hi, thanks for the deprecation notice in #256.

I'm currently on v0.3.1 and looking at migrating to v0.5.0. I'm using the operator to expose entire VPC CIDR ranges (not individual Kubernetes services) to NetBird peers. My current setup looks like this:

apiVersion: netbird.io/v1
kind: NBResource
spec:
  name: dev-vpc-cidr
  address: "10.100.0.0/16"
  groups:
    - dev-core-vpc
  policyName: "dev-vpc-admins"
  policySourceGroups:
    - Admins
  tcpPorts:
    - 22
    - 443
    - 5432

The intent is to give specific NetBird groups (e.g. Admins, Engineering, GitHub) access to the entire VPC via routing peers, with different port allowlists per group.

Looking at the new v1alpha1 API in v0.5.0, NetworkResource only accepts a serviceRef pointing to a Kubernetes Service — there's no address field for arbitrary CIDRs or IP ranges. I also checked the controller source (networkresource_controller.go) and confirmed that serviceRef is required and the ClusterIP is hardcoded as the resource address.

My question: Is there a supported way to expose a VPC CIDR (not a K8s Service) using the new API? Or is this use case not yet covered by v1alpha1?

If it's not supported yet, I'd love to know if it's on the roadmap — this pattern is common when using the operator purely for VPN-style access to the underlying network, rather than for service discovery within the cluster.

[phillebaba]

Thank you for describing your use case. I have not removed the old resources on purpose as I suspected there would be some I would miss.

If I understand things correctly, you are trying to expose resources outside of Kubernetes through a router running inside of a Kubernetes cluster. This means that we cannot use the service reference and instead need specific CIDRs instead. I think this should be doable, either by modifying the existing resource or adding a new one. I would prefer if we could change the service ref so that we could just expose static CIDRs instead.

[phillebaba]

This work is now tracked in #305.

[brian-provenzano]

I might have missed where to find this, but what is the new CR replacement for NBPolicy (since it does not function any longer). I cannot find a new 1:1 replacement here: https://github.com/netbirdio/kubernetes-operator#api or https://github.com/netbirdio/kubernetes-operator/blob/main/docs/api-reference.md

Thanks!