Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Use External Subnets for Service Controller

Open
#207 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
go, kubernetes
Domain
backend, cloud, networking

Research direction

Start in internal/provider/load_balancer.go, especially the current floating IP implementation and the load balancer status handling around the linked lines. Read the external subnet documentation and investigate how subnet pools, /32 allocation, annotations, and node listening would work. Done means establishing and implementing a viable external-subnet design that removes the current IP:PORT conflict limitation.

Written by the indexing model from the issue text.

Description

Enhancement Kubernetes Cloud Controller Manager (CCM)

The service controller currently uses floating IPs as the implementation for LoadBalancer services. This presents the following issues.

  • Floating IPs are transparent to the instance—traffic arrives on the instance's internal IP address instead of the floating IP address. To work around this we add the instance's internal IP address to the load balancer status, which is technically incorrect.
  • Due to the above point, we cannot create two different load balancers using the same service port on the same Kubernetes node. Otherwise, there will be a port conflict.

Let's explore using external subnets instead of floating IPs as the implementation for LoadBalancer services. This would solve the limitations with floating IPs, and create some new limitations, described below.

  • The subnet pool that the external subnet is allocated from must already exist and be provided to the LoadBalancer service. This could presumably be done using annotations (e.g., oxide.computer/subnet-pool).
  • Attaching an external subnet to an instance does not automatically make the instance listen on any of the IP addresses in that subnet. That is, there would need to be some mechanism to tell the Kubernetes node to listen on an IP address from the attached external subnet. I'm thinking the implementation would allocate /32 IP addresses from the external subnet and use that as the external address in the LoadBalancer status. That should configure the Kubernetes node to listen on that IP address but perhaps I'm mistaken and further discovery is needed here.

Assuming further discovery proves fruitful, switching to external subnets for LoadBalancer services could significantly improve the current state of Kubernetes on Oxide by lifting the IP:PORT conflict limitation that floating IPs currently have.

Dominant language
Go
Stars
6
Forks
2
Avg merge
2h 5m
Merged PRs (30d)
14

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oxidecomputer/oxide-cloud-controller-manager

All issues in oxidecomputer/oxide-cloud-controller-manager

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.