View a markdown version of this page

Configure Kubernetes Ingress for hybrid nodes - Amazon EKS

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 exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. To make use of Ingress resources, a Kubernetes Ingress controller is required to set up the networking infrastructure and components that serve the network traffic.

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.

EKS Hybrid Nodes Ingress

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

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

  1. 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
  2. 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
  3. 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
  4. 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-charts
    helm repo update eks
  5. 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 \ --version AWS_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
  6. Verify the AWS Load Balancer Controller was installed successfully.

    kubectl get -n kube-system deployment aws-load-balancer-controller
    NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s
  7. 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
  8. Create a file named my-ingress-alb.yaml with 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
  9. Apply the Ingress configuration to your cluster.

    kubectl apply -f my-ingress-alb.yaml
  10. 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-ingress
    NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress alb * my-ingress-alb-<random-string>.<region>.elb.amazonaws.com 80 23m
  11. 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 aims to standardize how networking resources for Ingress, Load Balancing, and Service Mesh are defined and managed in Kubernetes clusters.

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 and Cilium Gateway pages in the Cilium documentation.

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.enabled set to true as shown in the examples below. If you are using Cilium’s kube-proxy replacement feature, you do not need to set nodePort.enabled to true.

  • Cilium must be configured with envoy.enabled set to true as 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

  1. Helm installed in your command-line environment, see Setup Helm instructions.

  2. Cilium installed following the instructions in Configure CNI for hybrid nodes.

Procedure

  1. 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
  2. Create a file called cilium-gateway-values.yaml with the following contents. The example below configures Cilium Gateway to use the default load balancer mode and to use a separate cilium-envoy DaemonSet 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
  3. 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
  4. Confirm the Cilium operator, agent, and Envoy pods are running.

    kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium
    NAME 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