Configure for an Application Load Balancer

On the [Ingress for an Application Load Balancer] page, we have shown you how to install the Ingress Controller and create ingress via the Ingress Yaml file. The following are detailed meanings of the information you can set for an Ingress

Annotations

Use the annotations below when creating ingress to customize the Load Balancer to suit your needs:

Annotations	Required/Not required	Meaning
vks.vngcloud.vn/load-balancer-id	Optional	If you do not already have a previously initialized Application Load Balancer on the vLB system. Now, when creating an Ingress, leave this information blank. After you have implemented Ingress deployment following the instructions at Ingress for an Application Load Balancer . We will automatically create an ALB on your cluster. This ALB will be displayed on vLB Portal, details can be accessed here If you already have a previously initialized Application Load Balancer on the vLB system and you want to reuse the ALB for your cluster. Now, when creating an Ingress, enter the Load Balancer ID information into this annotation. After you have created Ingress according to the instructions at Ingress for an Application Load Balancer . If: Your ALB currently has 2 listeners in it: 1 listener has HTTP protocol configuration and port 80 If a listener has HTTPS protocol configuration and port 443, we will use these 2 listeners. Your ALB does not have either or both listeners with the above configuration, we will automatically create them. Attention: If your ALB has: 1 listener has HTTP protocol configuration and port 443 Or a listener configured with HTTPS protocol and portal 80 then when creating Ingress an error will occur. At this point, you need to edit valid listener information on the vLB system and recreate ingress.
vks.vngcloud.vn/load-balancer-name	Optional	Annotation vks.vngcloud.vn/load-balancer-namewill be used if you do not use annotation load-balancer-id. Annotation vks.vngcloud.vn/load-balancer-name only makes sense when you create a new Ingress resource. After the Ingress resource is successfully created, this annotation will be automatically deleted . Using this annotation after the Ingress resource is created will have no effect . When you use this annotation, if you do not already have a previously initialized Application Load Balancer on the vLB system. We will automatically create an ALB on your cluster. This ALB will be displayed on vLB Portal, details can be accessed here If you already have a previously initialized Application Load Balancer on the vLB system and you want to reuse the ALB for your cluster. Now, please enter the Load Balancer Name information into this annotation.
vks.vngcloud.vn/package-id	Optional	If you do not enter this information, we will use the ALB Small configuration by default. If you already have an ACTIVE vLB host and you want to integrate this host into your K8S cluster, please skip this information field.
vks.vngcloud.vn/tags	Optional	The tag is added to your ALB.
vks.vngcloud.vn/scheme	Optional	Default is internet-facing , you can change it to internal depending on your needs.
vks.vngcloud.vn/security-groups	Optional	By default, a default security group will be created according to your Cluster.
vks.vngcloud.vn/inbound-cidrs	Optional	Default All CIRD: 0.0.0.0/0
vks.vngcloud.vn/healthy-threshold-count	Optional	Default 3
vks.vngcloud.vn/unhealthy-threshold-count	Optional	Default 3
vks.vngcloud.vn/healthcheck-interval-seconds	Optional	Default 30
vks.vngcloud.vn/healthcheck-timeout-seconds	Optional	Default 5
vks.vngcloud.vn/healthcheck-protocol	Optional	Default TCP . The user can select one of the TCP/HTTP values
vks.vngcloud.vn/healthcheck-http-method	Optional	Default GET . User can choose one of GET / POST / PUT values
vks.vngcloud.vn/healthcheck-path	Optional	Default /
vks.vngcloud.vn/healthcheck-http-version	Optional	Default 1.0 . Users can choose one of the values ​​1.0, 1.1
vks.vngcloud.vn/healthcheck-http-domain-name	Optional	Default is empty
vks.vngcloud.vn/healthcheck-port	Optional	Default traffic port
vks.vngcloud.vn/success-codes	Optional	Default 200
vks.vngcloud.vn/idle-timeout-client	Optional	Default 50
vks.vngcloud.vn/idle-timeout-member	Optional	Default 50
vks.vngcloud.vn/idle-timeout-connection	Optional	Default 5
vks.vngcloud.vn/pool-algorithm	Optional	Default ROUND_ROBIN . The user can select one of the values ​​ROUND_ROBIN / LEAST_CONNECTIONS / SOURCE_IP
vks.vngcloud.vn/enable-sticky-session	Optional	Default false .
vks.vngcloud.vn/enable-tls-encryption	Optional	Default false
vks.vngcloud.vn/target-node-labels	Optional	Default is empty
vks.vngcloud.vn/certificate-ids	Optional	Default is empty

---

IngressClassName

The Ingress installed by the VNGCloud Ingress Controller will have the information IngressClassName = "vngcloud". You may not change this information.

---

DefaultBackend

• An Ingress without any rules will send all traffic to a single default service default backend, or if no host and path match the HTTP request in the Ingress Yaml file, traffic will be routed to the service default backend. For example below, we are configuring the default if the request does not satisfy any rule in the Ingress yaml file, it will go to service name: example-svc-1 with port number 8080

defaultBackend:
    service:
      name: example-svc-1
      port:
        number: 8080

---

TLS

You can secure Ingress by specifying a Secret that contains the TLS key and certificate. Currently Ingress only supports TLS port 443 and is the termination point for TLS (TLS termination). TLS Secret must contain fields with key names tls.crt and tls.key, which are the certificate and private key to use for TLS. Specifically, you need to specify:

• Host: the specified hosts will use the cert.

• SecretName: secret name containing cert.

---

Path types

Each path in Ingress has a corresponding pathType. There are three supported pathTypes:

• Exact: Matches the URL path with absolute precision and is case sensitive.

• Prefix: Matches based on the URL path prefix separated by /. Matching is case-sensitive and is performed on each element of the URL path. A component of the main URL path is a label separated by a / in the URL path (This means that the URL path can consist of multiple levels separated by /, each string is between two main / marks). is a label, each label is a component of the URL path). A URL request is considered to match a path field (configured in the Ingress specification) when the entire value of the path (which can include multiple components separated by /) matches the first labels (adjectives). left of the URL). For example /example1/path1 matches /example1/path1/path2, but not /example1/path1path2

Specific examples:

Path type	Path(s)	Request path(s)	Is there a match or not?
Exact	/example1	/example1	Have
Exact	/example1	/host1	Are not
Exact	/example1	/example1/	Are not
Exact	/example1/	/example1	Are not
Prefix	/	(all paths)	Have
Prefix	/example1	/example1,/example1/	Have
Prefix	/example1/	/example1,/example1/	Have
Prefix	/example1/host11	/example1/host1	Are not
Prefix	/example1/host1	/example1/host1	Have
Prefix	/example1/host1/	/example1/host1	Have
Prefix	/example1/host1	/example1/host1/	Have
Prefix	/example1/host1	/example1/host1/ccc	Have
Prefix	/example1/host1	/example1/host1xyz	Are not
Prefix	/,/example1	/example1/ccc	Have
Prefix	/, /example1,/example1/host1	/example1/host1	Have
Prefix	/, /example1,/example1/host1	/ccc	Have
Prefix	/example1	/ccc	Are not

• In some cases, multiple paths within Ingress will match the path of the request URL. In those cases, priority will be given to the longest matching path first. If the two paths still have the same length, the priority will be in the order of the rule created on the Ingress Yaml file.

---

Ingress rule

Each HTTP rule contains the following information:

• 1 optional host . If no host (we can understand it as a domain name) is specified, the rule will be applied to all HTTP traffic inbound to the specified IP address. If a host is specified (for example example1.com), the rule only applies to that host.

• A list of paths ( for example /example1/host1), each path has a backend service associated with it defined by Service Name and Port Number. Both host and path must match the content of the incoming request before the load balancer directs traffic to the desired Services.

• A backend is a combination of the Service name and Port Number. HTTP and HTTPS requests going to Ingress and whose URL matches the host and path of the rule will be sent to the list of backends.

For example, does Host match the Host header according to the table:

Host	Host header	Is there a match or not?
*.example1.com	example2.example1.com	Have
*.example1.com	baz.example2.example1.com	Are not
*.example1.com	example1.com	Are not