Please address the comments from this code review:

## Overall Comments
- The global `nextNodePort` counter is not concurrency-safe; if fake services are created from multiple goroutines, consider using `atomic.AddInt32` or a `sync.Mutex` to avoid races and duplicate ports.
- The `getUniqueNodePort` wrap-around at 32767 means ports will be reused once ~2.7k nodePorts are allocated; if scale tests can exceed this, consider increasing the range or tying the counter to the workload size to preserve uniqueness within a run.

Please address the comments from this code review:

## Overall Comments
- The global `nextNodePort` counter is mutated without synchronization; if fake services are ever generated from multiple goroutines this will race and produce incorrect or duplicated ports, so consider guarding it with a mutex/atomic or making the allocator instance-scoped.
- The IP generation logic using `fmt.Sprintf("10.%d.%d.%d", 128+(i/(256*256))%128, (i/256)%256, i%256)` is a bit opaque; extracting this into a small helper with a descriptive name or comment about the intended address space and max supported node count would improve readability and future modifications.

## Individual Comments

### Comment 1
<location path="sensor/kubernetes/fake/service.go" line_range="15-18" />
<code_context>
-	ipFamilies = [...]string{"IPv4", "IPv6"}
+	protocols          = [...]string{"TCP", "UDP", "SCTP"}
+	ipFamilies         = [...]string{"IPv4", "IPv6"}
+	nextNodePort int32 = 30000
 )

</code_context>
<issue_to_address>
**issue (bug_risk):** Global mutable nodePort counter is not concurrency-safe and may race under parallel usage.

If these helpers are called from multiple goroutines (common in concurrent tests), `nextNodePort` will race and may produce duplicate or invalid ports. Please synchronize access (e.g., with `atomic.AddInt32` or a mutex), or make the counter instance-scoped on a struct to keep concurrency behavior well-defined.
</issue_to_address>