Support for NodePort Services in ROSA/OSD

Feature Overview (aka. Goal Summary)  

This feature will support network applications on ROSA and OSD clusters that use NodePort services on clusters and bring their own Load Balancers to expose applications external to the cluster. Today, the port ranges on the worker nodes that are used by Kubernetes NodePort services are restricted to just cluster nodes that make it impossible to reliably run network applications.  

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Complete during New status.

• Security rules in the worker node security group to include inbound/outbound rules that open the TCP ports in the range of 3000-32767. 
• Customers can allow NodePort services at the machine pool resource level.   
• Support for enabling this after cluster is created (day-2) during machine pool creation.
• Support for enabling this during cluster creation (day-1)
• Support for changing this after cluster/machine-pool is created (day-2).
• Support for Classic and HCP topologies.
• Support for ROSA CLI, OCN UI and Terraform provider.
• SREP SOPs (alerts, monitoring, etc) updated to allow for SG rule changes in a way w/o removing/changing those SG rules needed for cluster functioning and SREP access.
• Support as opt-in wherein by default NodePort services are not enabled.
• Support for AWS regions where ROSA Services are available.
• Support for AWS Local Zones allowing for customers to use their private data center load balancers.
• ROSA and OSD documentation updated under Cluster creation (day-1) and Cluster Administration (day-2) sections
• Cluster telemetry is updated accordingly to capture Security Group/rules changes
• Amplitude/Segment captures feature usage.

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.