Help improve this page
To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.
Configure Kubernetes Ingress for hybrid nodes
This topic describes how to configure Kubernetes Ingress for workloads running on Amazon EKS Hybrid Nodes. Kubernetes Ingress
AWS supports AWS Application Load Balancer (ALB) and Cilium for Kubernetes Ingress for workloads running on EKS Hybrid Nodes. The decision to use ALB or Cilium for Ingress is based on the source of application traffic. If application traffic originates from an AWS Region, AWS recommends using AWS ALB and the AWS Load Balancer Controller. If application traffic originates from the local on-premises or edge environment, AWS recommends using Cilium’s built-in Ingress capabilities, which can be used with or without load balancer infrastructure in your environment.
AWS Application Load Balancer
You can use the AWS Load Balancer Controller and Application Load Balancer (ALB) with the target type ip for workloads running on hybrid nodes. When using target type ip, ALB forwards traffic directly to the pods, bypassing the Service layer network path. For ALB to reach the pod IP targets on hybrid nodes, your on-premises pod CIDR must be routable on your on-premises network. Additionally, the AWS Load Balancer Controller uses webhooks and requires direct communication from the EKS control plane. For more information, see Configure webhooks for hybrid nodes.
Considerations
-
See Route application and HTTP traffic with Application Load Balancers and Install AWS Load Balancer Controller with Helm for more information on AWS Application Load Balancer and AWS Load Balancer Controller.
-
See Best Practices for Load Balancing for information on how to choose between AWS Application Load Balancer and AWS Network Load Balancer.
-
See AWS Load Balancer Controller Ingress annotations
for the list of annotations that can be configured for Ingress resources with AWS Application Load Balancer.
Prerequisites
-
Cilium installed following the instructions in Configure CNI for hybrid nodes.
-
Cilium BGP Control Plane enabled following the instructions in Configure Cilium BGP for hybrid nodes. If you do not want to use BGP, you must use an alternative method to make your on-premises pod CIDRs routable on your on-premises network. If you do not make your on-premises pod CIDRs routable, ALB will not be able to register or contact your pod IP targets.
-
Helm installed in your command-line environment, see the Setup Helm instructions for more information.
-
eksctl installed in your command-line environment, see the eksctl install instructions for more information.
Procedure
-
Download an IAM policy for the AWS Load Balancer Controller that allows it to make calls to AWS APIs on your behalf.
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json -
Create an IAM policy using the policy downloaded in the previous step.
aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json -
Replace the value for cluster name (
CLUSTER_NAME), AWS Region (AWS_REGION), and AWS account ID (AWS_ACCOUNT_ID) with your settings and run the following command.eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve -
Add the eks-charts Helm chart repository and update your local Helm repository to make sure that you have the most recent charts.
helm repo add eks https://aws.github.io/eks-chartshelm repo update eks -
Install the AWS Load Balancer Controller. Replace the value for cluster name (
CLUSTER_NAME), AWS Region (AWS_REGION), VPC ID (VPC_ID), and AWS Load Balancer Controller Helm chart version (AWS_LBC_HELM_VERSION) with your settings and run the following command. If you are running a mixed mode cluster with both hybrid nodes and nodes in AWS Cloud, you can run the AWS Load Balancer Controller on cloud nodes following the instructions at AWS Load Balancer Controller.-
You can find the latest version of the Helm chart by running
helm search repo eks/aws-load-balancer-controller --versions.helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --versionAWS_LBC_HELM_VERSION\ --set clusterName=CLUSTER_NAME\ --set region=AWS_REGION\ --set vpcId=VPC_ID\ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller
-
-
Verify the AWS Load Balancer Controller was installed successfully.
kubectl get -n kube-system deployment aws-load-balancer-controllerNAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s -
Create a sample application. The example below uses the Istio Bookinfo
sample microservices application. kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml -
Create a file named
my-ingress-alb.yamlwith the following contents.apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: alb.ingress.kubernetes.io/load-balancer-name: "my-ingress-alb" alb.ingress.kubernetes.io/target-type: "ip" alb.ingress.kubernetes.io/scheme: "internet-facing" alb.ingress.kubernetes.io/healthcheck-path: "/details/1" spec: ingressClassName: alb rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix -
Apply the Ingress configuration to your cluster.
kubectl apply -f my-ingress-alb.yaml -
Provisioning the ALB for your Ingress resource may take a few minutes. Once the ALB is provisioned, your Ingress resource will have an address assigned to it that corresponds to the DNS name of the ALB deployment. The address will have the format
<alb-name>-<random-string>.<region>.elb.amazonaws.com.kubectl get ingress my-ingressNAME CLASS HOSTS ADDRESS PORTS AGE my-ingress alb * my-ingress-alb-<random-string>.<region>.elb.amazonaws.com 80 23m -
Access the Service using the address of the ALB.
curl -s http//my-ingress-alb-<random-string>.<region>.elb.amazonaws.com:80/details/1 | jq{ "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" "details": "This is the details page" }
Cilium Ingress and Cilium Gateway Overview
Cilium’s Ingress capabilities are built into Cilium’s architecture and can be managed with the Kubernetes Ingress API or Gateway API. If you don’t have existing Ingress resources, AWS recommends to start with the Gateway API, as it is a more expressive and flexible way to define and manage Kubernetes networking resources. The Kubernetes Gateway API
When you enable Cilium’s Ingress or Gateway features, the Cilium operator reconciles Ingress / Gateway objects in the cluster and Envoy proxies on each node process the Layer 7 (L7) network traffic. Cilium does not directly provision Ingress / Gateway infrastructure such as load balancers. If you plan to use Cilium Ingress / Gateway with a load balancer, you must use the load balancer’s tooling, commonly an Ingress or Gateway controller, to deploy and manage the load balancer’s infrastructure.
For Ingress / Gateway traffic, Cilium handles the core network traffic and L3/L4 policy enforcement, and integrated Envoy proxies process the L7 network traffic. With Cilium Ingress / Gateway, Envoy is responsible for applying L7 routing rules, policies, and request manipulation, advanced traffic management such as traffic splitting and mirroring, and TLS termination and origination. Cilium’s Envoy proxies are deployed as a separate DaemonSet (cilium-envoy) by default, which enables Envoy and the Cilium agent to be separately updated, scaled, and managed.
For more information on how Cilium Ingress and Cilium Gateway work, see the Cilium Ingress
Cilium Ingress and Gateway Comparison
The table below summarizes the Cilium Ingress and Cilium Gateway features as of Cilium version 1.17.x.
| Feature | Ingress | Gateway |
|---|---|---|
|
Service type LoadBalancer |
Yes |
Yes |
|
Service type NodePort |
Yes |
No1 |
|
Host network |
Yes |
Yes |
|
Shared load balancer |
Yes |
Yes |
|
Dedicated load balancer |
Yes |
No2 |
|
Network policies |
Yes |
Yes |
|
Protocols |
Layer 7 (HTTP(S), gRPC) |
Layer 7 (HTTP(S), gRPC)3 |
|
TLS Passthrough |
Yes |
Yes |
|
Traffic Management |
Path and Host routing |
Path and Host routing, URL redirect and rewrite, traffic splitting, header modification |
1 Cilium Gateway support for NodePort services is planned for Cilium version 1.18.x (#27273
2 Cilium Gateway support for dedicated load balancers (#25567
3 Cilium Gateway support for TCP/UDP (#21929
Install Cilium Gateway
Considerations
-
Cilium must be configured with
nodePort.enabledset totrueas shown in the examples below. If you are using Cilium’s kube-proxy replacement feature, you do not need to setnodePort.enabledtotrue. -
Cilium must be configured with
envoy.enabledset totrueas shown in the examples below. -
Cilium Gateway can be deployed in load balancer (default) or host network mode.
-
When using Cilium Gateway in load balancer mode, the
service.beta.kubernetes.io/aws-load-balancer-type: "external"annotation must be set on the Gateway resource to prevent the legacy AWS cloud provider from creating a Classic Load Balancer for the Service of type LoadBalancer that Cilium creates for the Gateway resource. -
When using Cilium Gateway in host network mode, the Service of type LoadBalancer mode is disabled. Host network mode is useful for environments that do not have load balancer infrastructure, see Host network for more information.
Prerequisites
-
Helm installed in your command-line environment, see Setup Helm instructions.
-
Cilium installed following the instructions in Configure CNI for hybrid nodes.
Procedure
-
Install the Kubernetes Gateway API Custom Resource Definitions (CRDs).
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml -
Create a file called
cilium-gateway-values.yamlwith the following contents. The example below configures Cilium Gateway to use the default load balancer mode and to use a separatecilium-envoyDaemonSet for Envoy proxies configured to run only on hybrid nodes.gatewayAPI: enabled: true # uncomment to use host network mode # hostNetwork: # enabled: true nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid -
Apply the Helm values file to your cluster.
helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-gateway-values.yaml -
Confirm the Cilium operator, agent, and Envoy pods are running.
kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=ciliumNAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s
Configure Cilium Gateway
Cilium Gateway is enabled on Gateway objects by setting the gatewayClassName to cilium. The Service that Cilium creates for Gateway resources can be configured with fields on the Gateway object. Common annotations used by Gateway controllers to configure the load balancer infrastructure can be configured with the Gateway object’s infrastructure field. When using Cilium’s LoadBalancer IPAM (see example in