Configure your cluster

Ingress is incoming traffic to your workloads. A VPC is a virtual private cloud network.

Private nodes, project-internal networking, and VPC ingress control different parts of the network:

• Private nodes use private addresses or subnets. Their workloads can still receive traffic through a public ingress load balancer.
• Project-internal networking connects workloads through their internal addresses within a project.
• VPC ingress exposes selected workloads through a private load balancer. Clients need network connectivity to the VPC to reach it.

Private subnet placement does not make workload ingress private. Private ingress does not make the Kubernetes API endpoint private or disable internet egress. It does not create an air-gapped cluster, which is isolated from external networks.

Choose cluster ingress

Northflank supports private ingress for eligible AWS, Azure, and GCP clusters. During cluster creation, the Load balancers panel offers these Provisioning options, where available:

In the cluster API, settings.networking.istio.enablePublicLoadBalancer defaults to true. The field settings.networking.istio.enablePrivateLoadBalancer defaults to false. At least one ingress load balancer must remain enabled.

Each workload also needs the corresponding exposure on its ports or addon. Enabling cluster ingress does not expose every workload.

Change an existing cluster

Support for switching ingress must be enabled when Northflank creates the cluster. Clusters created without this support reject later changes between these choices.

Northflank applies accepted changes after the save completes. A successful save does not mean that the ingress is ready.

For a supported cluster, open its Settings page. In Networking, select the ingress under Provisioning options. Click Save changes.

To move traffic to another ingress path:

1. Save a cluster configuration that enables the destination ingress.
2. Wait until its load balancer is ready.
3. Configure the affected workloads and routes to use the destination ingress.
4. Make sure that the workload endpoints are reachable from the intended client network.
5. Move clients to the destination path.
6. After no clients or workload routes require the old path, disable it in the cluster configuration.

AWS subnet and security-group limitations

Keep at least one public subnet in your AWS custom VPC, including for private-only ingress. You do not need to select that public subnet for the cluster. See custom VPC configuration.

Security groups control allowed network traffic. A limited AWS capability adds them to the private Network Load Balancer (NLB). Northflank selects this capability at creation for eligible clusters with all these properties:

• The cluster supports changing ingress and enables private ingress at creation.
• The cluster explicitly selects private subnets in at least two availability zones. These zones cover every node-pool availability zone.
• The cluster uses neither overlay networking nor custom launch templates. Overlay networking adds a separate network for workloads.

This capability does not automatically upgrade existing clusters. You cannot supply your own security-group IDs for it. You must configure any CloudFront integration and client connectivity to the VPC separately.

You can configure the build infrastructure for the clusters you create, which allows you to define where all builds in projects on that cluster will take place, and what compute resources will be granted to builds (build plans).

This option can be found under advanced when creating a cluster, or in settings on the details page for existing clusters.

Select a build cluster

You can select another cluster that you have provisioned specifically for builds, and the cluster you are currently configuring will then deploy all build workloads to the build cluster. All builds will use the build plan configured on the target build cluster.

This gives you the flexibility to:

• ensure build workloads have capacity to be scheduled and completed by using a pooled build cluster, separate from your deployment clusters
• ensure your deployments and jobs are not delayed by build workloads
• select spot instances to reduce costs
• use another cloud provider and different node types, if required

Build using the Northflank platform as a service

You can select this option to build using Northflank's platform as a service, paying only for the usage of compute resources. Specific build plans can be selected in each service or job.

Build on the same cluster

You can choose to build and deploy on the same cluster, and select the specific build plan for all builds to use. The selected build plan will override build plans selected by users in their services and jobs created on that cluster. You should ensure that your node pools have sufficient resources and nodes to provision both deployments and build workloads.

You can configure the minimum resources requested by pods on a cluster by changing the request modifiers under advanced when creating a cluster, or in settings on the details page for existing clusters.

A pod's main runtime container requests resources from a node according to the selected compute or build plan for a service, job, or addon. The request modifiers reduce the resources specified in the plan by a percentage, so a request modifier of 0.7 will request 70% of the resource defined in the plan. This defines the minimum resources that will be requested by a po from a node, but the pod can use the full amount of resources specified in the plan if there is available capacity on a node. The resources available to the pod will be throttled to the minimum request, as calculated by the pod's plan and the request modifiers, if the available resources are reduced by other pods deployed to the node. Sidecar containers will consume resources within the same pod as the main runtime container, and system pods will reduce resources available on the node.

Reducing the request modifiers allows you to over-provision a node with containers, which can optimise your costs if your workload's average requirements are expected to be smaller than the resources of the selected plan. For example, you could provision a node with 10 vCPUs and use compute plans that request 2 vCPUs for deployment services, which would mean that 5 containers could be deployed on a node (ignoring overheads). By setting the service CPU request modifier to 0.5 the same node could now deploy up to 10 containers for the deployment service, with each container throttled to less than 2 vCPU as more workloads are deployed on the node, until they reach a minimum of 1 vCPU for each container.

Request modifiers affect all container deployments on the cluster, and will reduce the resources requested by all compute and build plans by the same percentage. Changing the request modifiers for addons on an existing cluster will restart any addons on the cluster.

By default, Northflank will delete all volumes and volume snapshots (from addon backups) when you delete a cluster.

If you want to retain these volumes you can expand the advanced menu and uncheck them, or uncheck them in the settings on an existing cluster, on the cluster details page.

Please note that you will still be billed by your cloud provider for any volumes left after cluster deletion. You should always delete your Northflank-created clusters through the Northflank interface to avoid orphaned resources.