Create a static internal IP on the internal network for virtual login node.

Summary

The communication between the SSH proxy and the backend host occurs over the internal network. To ensure proper routing, a login node with a stable internal IP in the 10.250.0.0/16 range must be created. This allows the SSH proxy to consistently resolve the login node's hostname across deployments. Without a stable IP, the internal IP must be updated manually after each deployment, leading to operational inefficiencies. The current solution to this issue breaks in prod when you try to define a port on the knightly-network because of dual IP assignment from the same network.

Current Behavior

During deployment, a static internal IP is assigned by specifying the internal port ID through pipeline variables. This approach works as expected in both the development and staging environments, where:

• The internal network is assigned via port ID.
• The external network is assigned via network ID.

Issue in Production

In the production environment, post-deployment, the SSH proxy was unable to route traffic and remained unresponsive. Upon investigation, it was observed that the login node was assigned two internal IPs. This issue arose because:

Both the port ID and network ID referenced the same network. While defining a port is optional, the --network option was always provided, causing dual IP assignment.

Proposed Solution

To prevent dual IP assignment and ensure flexibility in deployment, the --network option should be made optional. This change will allow a single static internal IP assignment via the port or network definition, ensuring a consistent and predictable deployment process across all environments, including production.