aws-load-balancer-controller icon indicating copy to clipboard operation
aws-load-balancer-controller copied to clipboard

Published 20 hours ago • verified publisher icon kubernetes-sigs

Support flag to change the default target-type

Open johngmyers opened this issue 3 years ago • 1 comments

Is your feature request related to a problem?

The desired target type of an ALB or NLB is almost always determined by the the cluster's CNI. If a cluster's CNI uses ENIs (like AWS VPC CNI does) then the desired target type is ip. If a cluster's CNI uses masquerading, then the desired target type is instance.

When a cluster's CNI uses ENIs, it is a burden to require each workload's Ingress and Service resources to include an LBC-specific annotation in order to function.

Describe the solution you'd like

Add a flag to the controller to set the default target-type. The value of the flag would be stored in the defaultTargetType field of defaultModelBuildTask. This would require a new field be added to defaultModelBuilder and a new parameter be added to NewDefaultModelBuilder.

Describe alternatives you've considered

Add a field to IngressClassParams. While this would reduce the size of the burden from one-per-Ingress to one-per-IngressClass, there isn't a likely use case where one would want different IngressClasses in the same cluster to have different default target-types.

johngmyers avatar Jun 15 '22 00:06 johngmyers

/kind feature Currently, the default target type for Ingress and Service with loadBalancerClass is instance. The load balancer class is supported in k8s 1.22 and later versions. For legacy service, we want to rely on the load balancer type, and the target type attribute both and not depend on the default target type.

For the cases we use default instance type, we will provide a flag to configure ip target type as defalt.

/kind feature

kishorj avatar Aug 11 '22 22:08 kishorj

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Nov 09 '22 22:11 k8s-triage-robot

/remove-lifecycle stale

johngmyers avatar Nov 09 '22 23:11 johngmyers