Lecture 248: Exposing services using ClusterIP, NodePort, LoadBalancer and Ingress
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：20:47
- 来源：Udemy Lecture 35813160
- Slide 数量：10
- 画面切换：03:39、05:59、08:01、10:25、12:01、13:16、15:30、17:45、20:15
扫描说明
逐条读取了 Transcript 面板中的 445 条英文 cue，并按播放器进度同步全长约 20:47 的视频。依据 Service Abstraction、ClusterIP、NodePort、Controller Selection、Legacy LoadBalancer、AWS Load Balancer Controller/NLB、Ingress/ALB、IngressGroup/Target Mode、NLB Client IP、ALB Client IP 划分为 10 个小节。10 张截图来自真实课程 Slide，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Kubernetes Service 为易失 Pod 提供稳定的 Discovery 与 Traffic Abstraction
时间范围：00:00–03:39
总结 / Summary
中文
Pod 会因 Scaling、Rescheduling、Node Replacement 或 Rollout 被销毁/重建，Pod IP 与所在 Node 都会变化，因此 Client 不应把 Pod IP 当作稳定 Endpoint。Kubernetes Service 用 Selector/EndpointSlice 把一个稳定的 DNS Name、Virtual IP 或 External Front Door 映射到当前 Ready Pod。核心暴露方式是 ClusterIP、NodePort、LoadBalancer；Ingress 严格来说不是 Service Type，而是独立的 L7 Routing API Resource，通常把多个 Service 放在同一个 HTTP/HTTPS Entry Point 后。
English
Pods are destroyed and recreated by scaling, rescheduling, node replacement, and rollouts, so neither pod IPs nor node placement are stable client endpoints. A Kubernetes Service uses selectors and EndpointSlices to map a stable DNS name, virtual IP, or external front door to currently ready pods. The principal service types are ClusterIP, NodePort, and LoadBalancer. Strictly speaking, Ingress is not a service type; it is a separate Layer 7 routing API resource that commonly places multiple Services behind one HTTP or HTTPS entry point.
Transcript
00:00 Hello and welcome to this lecture,
00:01 "Exposing EKS Services."
00:04 If you're running some application, it is evident
00:07 that you will be exposing that to the outside world
00:10 so that outside world can consume your services.
00:13 Okay. So why service, first of all?
00:16 Now this is very similar to any other service
00:18 that you will expose for any other application,
00:21 whether it is hosted on EC2 machine
00:23 or it is hosted on containers inside EC2.
00:27 But then you want to expose services outside.
00:30 Service could be your API,
00:32 it could be your front end service,
00:34 it could be your database service, right?
00:36 So in Kubernetes, you know that you have pods.
00:38 Pods gets an IP address as well.
00:42 And generally speaking, it's not a great idea
00:44 to expose the pod's IP address externally
00:47 so that the external client can communicate
00:49 with the pod's IP address directly.
00:52 This is because, you know pods are
00:53 non-permanent objects of the Kubernetes cluster.
00:57 So the life cycle of pod
00:59 is not supposed to be the long term, right?
01:01 And for the same reason that pods may be created
01:05 and destroyed based on scale,
01:08 based on the event in the Kubernetes cluster,
01:12 maybe more random kind of, right?
01:15 So pods inside a cluster always
01:17 keeps moving across the nodes.
01:19 As I said, due to scaling event or node replacement
01:22 or maybe some configuration change you made.
01:25 And that's where if the pod changes its location,
01:30 its IP address will also change.
01:32 And that's where it is not recommended
01:35 to use pod's IP addresses directly.
01:37 The better ways to expose the pod
01:40 as a service to the outside world, right?
01:43 So that's where services are useful.
01:46 Now in Kubernetes world,
01:47 if you want to expose pod services externally
01:51 or in general if you want to make a service out
01:53 of the pod, then there are four ways, right?
01:57 So very first type of the service is cluster IP.
02:02 Now this is for the service
02:03 to be exposed within the cluster.
02:05 That means one pod can access another pod
02:09 as a service within the cluster only.
02:11 That means it cannot be accessed from outside the cluster.
02:15 It is good if all the communication for
02:17 those services remains within the cluster
02:20 and you don't need to expose that externally.
02:23 If you still want to expose the pod services externally,
02:27 then there is another service type called NodePort.
02:30 Now here, instead of pod IP addresses,
02:33 you are exposing the node IP addresses externally.
02:36 That means client can directly hit
02:38 the node IP address and/or static port,
02:41 and then it'll be redirected to the pod traffic, right?
02:45 So that's another way.
02:46 Again, we'll see why this is also not a good idea.
02:49 Now actually speaking, if you really want to expose
02:53 the services of the Kubernetes then it is best idea
02:56 to use a load balancer service and the ingress service.
03:01 So load balancer service typically used
03:03 for network layer load balancing, that is layer four.
03:07 And there are some differences
03:08 in which EKS has implemented that.
03:11 I'll talk about that shortly.
03:13 And the latest way of having the application load balancing
03:16 at layer seven is ingress service of Kubernetes.
03:21 Now, these are all defined by the Kubernetes,
03:23 and you know that EKS implements all these services
03:25 using AWS native services like network load balancer
03:29 or application load balancer.
03:31 And we'll see that in this lecture.
03:34 But essentially there are these four ways
03:36 in which Kubernetes services can be exposed.
2. ClusterIP：Cluster 内部 Virtual IP + DNS，经 kube-proxy 转到 Ready Endpoint
时间范围：03:39–05:59
总结 / Summary
中文
ClusterIP 是默认 Service Type，只在 Cluster Network 内可达。API Server 从 Service CIDR 分配一个 Virtual IP，并由 CoreDNS 提供 service.namespace.svc.cluster.local 名称；kube-proxy 在 Node 上用 iptables、IPVS 或 nftables 等实现把 VIP:Port 转到 EndpointSlice 中的 Pod IP:targetPort。VIP 不是某块 ENI 的真实地址，也不是逐个绑定在 Node 上，而是由每个 Node 的 Data-plane Rule 实现。EKS 可在创建时指定 Service IPv4 CIDR；未指定时会从平台默认范围选择，必须避免与 VPC/Connected Network CIDR 重叠。
English
ClusterIP is the default service type and is reachable only inside the cluster network. The API server allocates a virtual address from the service CIDR, CoreDNS publishes service.namespace.svc.cluster.local, and kube-proxy uses iptables, IPVS, nftables, or another supported data plane on each node to translate the VIP and port to pod IP and targetPort entries from EndpointSlices. The VIP is not a real ENI address or individually attached to each node; it is implemented by per-node forwarding rules. EKS can accept a service IPv4 CIDR at creation, or select a platform default, and it must not overlap VPC or connected-network CIDRs.
Transcript
03:39 Okay, so let's look at the cluster IP now.
03:42 So as the name suggests, accessible only within the cluster.
03:46 And this is a default service type of the Kubernetes.
03:49 Now in this, what happens really is,
03:52 when you create a cluster IP as a service,
03:54 Kubernetes assigns a virtual IP
03:58 and then it exposes as a service.
04:01 So service is exposed on a virtual IP
04:03 and this IP is not exposed outside of a cluster.
04:06 Now if you see this diagram, there are three nodes,
04:09 and then there is one single service which is created.
04:13 And there is this virtual IP.
04:15 This is not an IP of the node
04:17 but this is a different IP address called virtual IP.
04:21 So you must be wondering from where this IP is allocated.
04:24 So when you create a Kubernetes cluster,
04:26 you can provide the CIDR range for this cluster IP addresses
04:31 and then Kubernetes will pick
04:33 any of the IP address from that range.
04:36 So you can pass this parameter service cluster IP range.
04:39 And if you don't pass it, EKS uses 10.100.0.0/16
04:44 or 172.20.0.0/16 server data range
04:48 for assigning to the cluster virtual IP.
04:51 And the kube-proxy daemon
04:53 on each cluster node defines the cluster IP
04:55 to the port IP mapping in the IP table rules.
04:57 That means the cluster IP service uses
05:00 IP table rules to really route the traffic
05:03 to respective ports across different nodes.
05:06 So this is how cluster IP works, but the limitation
05:09 as you know, it is only accessible within the cluster.
05:14 The services exposed as
05:15 the service-name.namespace.svc.cluster.local,
05:19 you can see you can give the name to the service
05:22 and then the name space could be different enrollments
05:25 or different business units likewise, right?
05:28 So that's the cluster IP service.
05:30 Now, how do you really deploy the cluster IP?
05:32 So you know that in Kubernetes
05:34 you have to write a manifest file.
05:36 So this is a sample manifest file
05:38 for cluster IP type of the service.
05:40 The most important for you here is the type
05:42 of the service that is a cluster IP.
05:44 And then you need to define the port as well
05:46 on which this service will be listening
05:49 and then which all ports it'll send traffic to,
05:52 which is done using the labels as you know, in Kubernetes.
05:57 So this is a sample file there.
3. NodePort：每个 Node 在同一高位 Port 暴露 Service，底层仍依赖 ClusterIP
时间范围：05:59–08:01
总结 / Summary
中文
NodePort 在每个 Node IP 上打开相同 Port，默认范围为 30000–32767；Packet 到任一 NodeIP:NodePort 后，经 kube-proxy 转到该 Service 的 Endpoint，内部仍建立在 ClusterIP/Service Routing 之上。每个 Service 占用一个 NodePort，Client 若直接依赖 Node IP 还要处理 Node Churn、Health 与 Firewall，因此很少作为公网最终入口。但它不是绝对 Anti-pattern：Load Balancer 的 Instance Target Mode 正是把健康 Node 的 NodePort 注册为 Target，由外部 LB 提供稳定 Endpoint。
English
NodePort opens the same port on every node address, using the default range 30000 through 32767. Packets arriving at any NodeIP and NodePort are forwarded by kube-proxy to a Service endpoint, still building on ClusterIP or Service routing underneath. Each Service consumes a NodePort, and clients that address nodes directly must handle node churn, health, and firewall rules, so it is rarely the final public entry point. It is not inherently an anti-pattern: load balancers in instance target mode register healthy node NodePorts and provide the stable external endpoint.
Transcript
05:59 Moving on, the next service type
06:01 as we just discussed, is NodePort.
06:03 In this case, you can see this diagram.
06:05 Every node has a node IP
06:07 and then there will be a static port.
06:10 So every service will be exposed as a node port.
06:13 So if you want to hit that service
06:15 you can pick node IP of any of the nodes here
06:18 on the static port, maybe 80, 80, 80, right?
06:22 And then ultimately the traffic will land
06:24 into the port IP address on that particular node.
06:27 So NodePort is used to make the Kubernetes services
06:30 accessible from outside the cluster
06:33 and exposes the service on each worker node's IP
06:36 at the static port, called NodePort.
06:40 So most important thing here to note
06:42 that it's one node port per service.
06:45 That means if your Kubernetes cluster has 10 services
06:47 to be exposed outside, you need to have 10 static ports.
06:52 So every node would have 10 different ports
06:55 allocated for that service, right?
06:57 And that's how it works.
07:00 Port range you can use from 30000 to 32767.
07:04 And then internally, this node port uses the cluster IP
07:08 to route traffic to particular pod IP address.
07:12 So ultimately there is a pod on top of pod,
07:16 there is a cluster IP service, and on top
07:17 of cluster IP there is a NodePort service.
07:20 So this is a layered service architecture you can see here.
07:25 Now do you think this is a great idea to use
07:28 a NodePort service type because it's the same problem
07:32 like it's anti pattern to use port IP address.
07:35 It's also anti pattern to use node IP address
07:38 because even nodes keep changing,
07:41 they die, new nodes come to the life.
07:43 And in that case, client would have to keep track
07:46 of which is the active node and only should
07:48 be able to hit that node, right?
07:51 So that's a problem and not a very feasible option
07:53 to expose services to the outside world.
07:56 So we just saw two services
07:57 as of now Cluster IP and NodePort.
07:59 But the right way probably to expose the services
4. EKS 的推荐分工：LoadBalancer Service → NLB，Ingress → ALB
时间范围：08:01–10:25
总结 / Summary
中文
L4 TCP/UDP/TLS Exposure 通常使用 Service type: LoadBalancer 配合 Network Load Balancer；L7 HTTP/HTTPS 的 Host/Path Routing 使用 Ingress 配合 Application Load Balancer。历史上 Kubernetes In-tree AWS Cloud Provider 负责 LoadBalancer Service，曾创建 CLB，后来也支持 NLB Instance Mode；现代 EKS 推荐 AWS Load Balancer Controller（原 AWS ALB Ingress Controller），同时管理 Service→NLB 与 Ingress→ALB。讲师称 Ingress 为 ServiceType=Ingress 属于概念简化，Manifest 中应创建 kind: Ingress 并引用后端 Service。
English
Layer 4 TCP, UDP, or TLS exposure generally uses a LoadBalancer Service with a Network Load Balancer, while Layer 7 HTTP or HTTPS host and path routing uses an Ingress with an Application Load Balancer. Historically, the Kubernetes in-tree AWS cloud provider handled LoadBalancer Services, first creating CLBs and later supporting NLB instance mode. Modern EKS recommends the AWS Load Balancer Controller, formerly the AWS ALB Ingress Controller, for both Service-to-NLB and Ingress-to-ALB reconciliation. Calling Ingress ServiceType=Ingress is a conceptual simplification; a manifest creates kind: Ingress and references backend Services.
Transcript
08:01 is the load balancer and the ingress.
08:04 And let's talk about those.
08:06 So in EKS you could handle the network
08:08 and application load balancing for
08:10 network load balancing which is that layer four.
08:13 Typically you should use service type as load balancer.
08:16 And for application load balancing,
08:18 you should use Kubernetes service type as ingress.
08:21 Now, there is some kind of overlap
08:23 between how EKS implement these two services
08:27 and let's try to understand that.
08:29 So originally the load balancer service type
08:33 in EKS used to be handled
08:34 by Kubernetes controller manager
08:37 which is also called Entry Cloud Controller
08:39 because the source code of this controller
08:41 was part of the Kubernetes open source code.
08:44 So it came bundled with the Kubernetes
08:47 and by default it used to create the classic load balancer
08:51 which you know is the older load balancer
08:53 which AWS used to support and lately now it supports NLB,
08:58 that is network load balancer in instance mode.
09:01 So if you're using the service type as a load balancer
09:05 and with in-tree cloud controller, then you can use CLB
09:08 or NLB in instance mode with this load balancer.
09:12 And then it supports both layer four
09:14 and layer seven traffic, layer four with NLP
09:17 and layer four or seven with CLB.
09:19 That is classic load balancer.
09:21 But as I said, this is a legacy way
09:23 of implementing the load balancer service.
09:26 If you want to really use the latest feature of NLB
09:30 then you should be using the newer controller
09:32 called ALB load balancer controller
09:35 with which you can use NLB.
09:37 You can't use CLB and it is not recommended to use CLB now.
09:42 So rather you go with the AWS load balancer controller
09:45 and then you use NLB for service type as load balancer.
09:49 For ingress service type, ingress means
09:53 that you should be able to have the pod base routing,
09:57 host base routing, all those features
09:59 you know that application load balancer supports.
10:02 So this is handled by the AWS load balancer controller
10:05 which is a new controller.
10:07 Earlier this controller used to be called
10:09 the AWS ALB Ingress Controller, but now everything
10:12 is combined as AWS load balancer controller
10:17 and then it deploys ALB in both instance and IP mode
10:21 for this ingress resource and it works at layer seven.
5. Legacy In-tree LoadBalancer 走 NodePort/Instance Target，CLB 路径应视为历史
时间范围：10:25–12:01
总结 / Summary
中文
旧 In-tree Controller 创建 CLB 或 NLB Instance Target。type: LoadBalancer 会隐式创建 NodePort；Load Balancer 把 Traffic 发到 NodeIP:NodePort，kube-proxy 再转到本机或其他 Node 的 Pod，所以路径为 LB → NodePort → Service → Pod。该模式只能把 EC2 Node 注册为 Target，无法直接注册 Pod IP/Fargate。CLB 与 In-tree Cloud-provider Integration 已是 Legacy；考试可能考迁移背景，但新架构应优先 AWS Load Balancer Controller，并核对当前 Kubernetes/EKS 对 In-tree Provider 的弃用状态。
English
The legacy in-tree controller creates a CLB or an NLB with instance targets. A LoadBalancer Service implicitly allocates a NodePort; the load balancer sends traffic to NodeIP and NodePort, and kube-proxy forwards it to a local or remote pod, producing the path LB to NodePort to Service to Pod. This mode registers EC2 nodes rather than pod IPs and cannot directly target Fargate pods. CLB and in-tree cloud-provider integration are legacy. Exams may test the migration history, but new designs should prefer AWS Load Balancer Controller and verify the current Kubernetes and EKS deprecation state.
Transcript
10:25 Now let's look at the load balancer service type
10:27 with the legacy controller.
10:28 As you know that there are two controllers,
10:30 one which is in-tree controller and the other one
10:34 is AWS load balancer controller, which is the newest one.
10:37 So first look at the older controller.
10:40 So of course the load balancer service is used to expose
10:42 the services to the client outside of the cluster.
10:45 Now interesting to know that when you configure service
10:49 as a load balancer, internally it uses the NodePort service.
10:53 So essentially what it does on every node,
10:56 a static port is assigned and this load balancer service
10:59 will send the request to the node IP
11:02 and the corresponding port.
11:04 That means underlying it's using the node port service.
11:08 And you already know that NodePort service
11:10 is built on top of the cluster IP service.
11:13 So there are three layers here, right?
11:15 You expose service as load balancer
11:17 but internally it uses other services.
11:21 So load balancer service with legacy controller supports
11:23 both the classic load balancer as you know
11:27 and the network load balancer.
11:29 Now with classic load balancer, you can have
11:32 both the traffic at layer four and layer seven
11:35 and with NLB, you could have the traffic at layer four.
11:40 Now one more thing that it only supports the instance mode
11:43 for the NLB and does not support target as IP addresses.
11:48 Now that problem is solved using
11:50 the latest controller that we'll talk about,
11:53 but just one more time, this is a legacy controller
11:56 and you are not really recommended to use
11:58 classic load balancer with this legacy controller.
6. AWS Load Balancer Controller 为 NLB 提供 Instance 与 IP Target Mode
时间范围：12:01–13:16
总结 / Summary
中文
AWS Load Balancer Controller Watch Service/Ingress Resource，并通过 Annotation/Service Attribute 创建 AWS Load Balancer。NLB Instance Mode 注册 Node 与 NodePort，兼容 EC2 Node；IP Mode 直接注册 Pod IP，少一跳、无需 NodePort Data Path，并可覆盖 Fargate。通常每个 LoadBalancer Service 创建一台 NLB，因此大量独立 Service 会增加 Cost、Quota 与 Operations；L4 Service 确实需要独立 Endpoint 时可接受，HTTP/HTTPS 多服务 Consolidation 则更适合 ALB Ingress/Gateway API。
English
AWS Load Balancer Controller watches Service and Ingress resources and creates AWS load balancers from annotations or service attributes. NLB instance mode registers nodes and NodePorts for EC2-backed clusters. IP mode registers pod addresses directly, removes a NodePort hop, and supports Fargate targets. A separate NLB is normally created for each LoadBalancer Service, so many independent Services add cost, quota pressure, and operational overhead. That can be appropriate for distinct Layer 4 endpoints, while HTTP or HTTPS consolidation is better suited to ALB Ingress or Gateway API.
Transcript
12:01 Rather, you should use NLB.
12:03 And for NLB, you should also use the latest controller
12:07 which is AWS load balancer controller.
12:10 So here you can see that now you can only use NLB
12:13 for load balancer service and you get many more features.
12:17 For example, you can use NLB in both
12:19 the instance mode as well as in the IP mode.
12:22 That means you could have your target
12:24 as EC2 machine IP addresses as well
12:27 as Fargate as your target.
12:29 And these are the supporting annotations there.
12:32 You could have EC2S target in instance mode
12:34 and then these are the annotations that you can use.
12:37 Now, one thing to understand that whenever
12:40 you are using load balancer as a service,
12:42 for every service, you need to have one load balancer.
12:45 That is one NLB, which means if you're exposing 10 services
12:49 then 10 network load balances will be required.
12:52 Now, this works well for maybe less number of services,
12:55 but as it scales to maybe hundreds of services,
12:58 it doesn't make sense to have those many
12:59 network load balancer and that's the problem
13:02 with load balancer service.
13:04 As it scales, the management is an overhead
13:06 and there will be a additional cost for those load balancer.
13:11 And now let's see how to solve that problem
13:12 by moving to ingress type of the service.
7. Ingress + ALB 用 Host/Path Rule 把多个 HTTP Service 汇聚到 Listener/Target Group
时间范围：13:16–15:30
总结 / Summary
中文
Ingress 描述 HTTP/HTTPS Host/Path Rule；AWS Load Balancer Controller 把它翻译为 ALB、Listener、Rule、Target Group、Health Check 与 Security Group Configuration。例如 /products 与 /accounts 可指向不同 Service/Target Group，一台 ALB 因而承载多个 Backend，减少每 Service 一台 NLB 的成本。Target Type instance 让 ALB 走 NodePort；ip 直接注册 Pod IP，适合 VPC CNI/Fargate 并避免跨 Node 转发。Ingress 只处理 L7，非 HTTP Protocol 仍用 NLB/其他 Gateway。
English
Ingress declares HTTP or HTTPS host and path rules. AWS Load Balancer Controller translates them into an ALB, listeners, rules, target groups, health checks, and security-group configuration. Paths such as /products and /accounts can reference different Services and target groups, allowing one ALB to host multiple backends and reducing the cost of one NLB per Service. Target type instance sends ALB traffic through NodePorts, while ip registers pod addresses directly for VPC CNI or Fargate and avoids cross-node forwarding. Ingress is Layer 7 only; non-HTTP protocols still require NLB or another gateway.
Transcript
13:16 And that's where Kubernetes Ingress is the right way.
13:20 If you have the application layer lower balancing,
13:23 in this case, it exposes services
13:25 to the client outside of the cluster.
13:27 And then it exposes HTTP and HTTPS routes
13:30 from outside the cluster to services within the cluster.
13:33 Now you can see this picture, right,
13:34 there is a application load balancer, and then,
13:37 you can have the pod based routing say
13:40 slash service one, service two or slash product.
13:43 And this is links to the target group.
13:45 And then target group could have the target
13:48 as an instance or target as an IP address, right?
13:51 Both are shown here.
13:52 So ALB is the ingress resource for EKS.
13:57 Now this traffic routing is controlled
13:59 by the rules as defining the ingress resource.
14:01 And of course this saves you cost
14:02 and complexity as now multiple services can be added
14:06 behind a single ALB using the ALB target group.
14:10 Like earlier we saw that if there are 10 services,
14:12 10 network load balancer needs to be provisioned.
14:15 But now every service might have a different endpoint,
14:18 say slash service one slash service two,
14:21 every service is wrapped around in a single target group.
14:24 And by doing the pod based routing,
14:26 you could redirect traffic to different services.
14:28 So for 10 services, you just need
14:31 to have now one load balancer in that sense.
14:33 So it saves you a lot of cost, right?
14:35 And management as well.
14:37 So this is a great way to simplify your architecture
14:39 using the Kubernetes Ingress resource.
14:42 And as I said, for having the Ingress resource,
14:46 EKS uses AWS load balancer controller
14:49 which used to be called AWS Ingress controller
14:52 but has been now renamed too.
14:54 So that's Kubernetes Ingress resource.
14:57 This is an AWS implementation of ingress controller.
15:00 It ultimately translates the ingress rules,
15:02 parameters and annotation into the ALB configuration.
15:05 So what ingress does ALB can also do,
15:08 the pod based routing, the whole space routing.
15:10 ALB also can create multiple listeners
15:12 and multiple target groups, right?
15:15 It supports both the target as instance or a port IP
15:19 and you can choose whichever way you want to implement that.
15:22 So annotations for Ingress class, you have to select the ALB
15:27 and then you can also share ALB with multiple services.
8. IngressGroup 可跨 Manifest 共享 ALB；Dual-stack 与 Target Type 要成套设计
时间范围：15:30–17:45
总结 / Summary
中文
多个 Ingress 使用相同 alb.ingress.kubernetes.io/group.name 可合并到同一 ALB，Controller 汇总 Rule；现代配置也可用 spec.ingressClassName/IngressClass，而旧 kubernetes.io/ingress.class: alb Annotation 仍常见。IngressGroup 是共同 Trust Boundary：能写同 Group Ingress 的主体可新增或覆盖 Shared ALB Rule，因此应限制 RBAC。Dual-stack ALB/NLB 需要相应 ip-address-type，课程指出 IPv6 Target Path 依赖 IP Target Mode。端到端上，Instance Target 走 NodePort，IP Target 直接到 Pod；Subnet Tag、AZ、SG 与 Health Check 必须匹配。
English
Multiple Ingress resources can share one ALB by using the same alb.ingress.kubernetes.io/group.name, allowing the controller to merge their rules. Modern manifests can also use spec.ingressClassName and an IngressClass, while the older kubernetes.io/ingress.class: alb annotation remains common. An IngressGroup is a shared trust boundary: anyone able to write an Ingress in the group can add or override shared ALB rules, so RBAC matters. Dual-stack ALBs or NLBs require the corresponding ip-address-type, and the lecture presents IPv6 target paths through IP target mode. Instance targets use NodePort, while IP targets go directly to pods; subnet tags, AZs, SGs, and health checks must align.
Transcript
15:30 Now what is that?
15:31 So for example, you have multiple business units
15:33 and they're operating by providing their own manifest file.
15:37 And suppose one business unit owns two services
15:39 and they use their single ALB,
15:42 but other group might have their own set
15:45 of services and they also want to expose that.
15:48 Now, if also they define their own manifest file,
15:50 Kubernetes will probably try to create
15:52 another load balancer for them.
15:54 But then what you want is you want single load balancer,
15:57 which is shared across all these services.
16:00 In that case, you can create something called a group
16:03 and if both the manifest file defines the same group name
16:06 then all the services will be exposed
16:08 as a part of the same application load balancer.
16:12 So this is how you could manage, you know,
16:14 how many load balancers you want to create
16:17 and share the load balancer across those services.
16:20 Now traffic for IPv6 is also supported
16:24 and for that you have to define the annotation.
16:27 Again, that IP address type is dual stack
16:30 and it is supported only for IP targets,
16:32 not for the instance target.
16:35 So that's the way EKS implements the ingress
16:38 for Kubernetes using the ALB load balancer controller
16:42 and using ALB as the resource.
16:45 So you can see ALB is at the top
16:48 and the client would hit the ALB DNS,
16:51 which transfers to the IP address.
16:53 And then from here, ALB would route the traffic
16:57 to either target group A or B,
16:58 depending on the path that user specifies.
17:01 And this target group could have the target
17:03 as an instance or the IP address.
17:06 If it's an IP address,
17:07 then target group registers the ports directly
17:10 so traffic directly goes to the ports
17:13 but if the target is instance, then ultimately it uses
17:16 the NodePort on every node and then NodePort
17:20 internally uses the cluster IP as a service.
17:22 So all that we learned,
17:24 the cluster IP NodePort is still applicable
17:27 if you are using the instance as a target
17:29 for your load balancer or ingress service.
17:32 So this is how end-to-end traffic works
17:34 in case of the ALB.
17:36 So I hope that is clear, maybe confusing,
17:39 but if you just go over this lecture one more time
17:41 probably things would be much easier for you to understand.
9. NLB Instance Mode 的 externalTrafficPolicy：Cluster 均衡性 vs Local Client IP
时间范围：17:45–20:15
总结 / Summary
中文
对经 NodePort 的 NLB Instance Target，externalTrafficPolicy: Cluster 是默认值：任一健康 Node 可接收后再转到 Cluster 任意 Endpoint，分布较均匀，但跨 Node 转发可能 SNAT 为 Node IP，使 Pod 看不到原始 Client IP。Local 只转到入口 Node 上的 Local Endpoint，可保留 Client Source IP 并减少一跳，但无 Local Pod 的 Node 不应接收流量，Pod 分布不均还会造成 Hot Spot。必须结合 Health Check、Topology Spread、DaemonSet/Replica Placement 与 Traffic Imbalance 评估。NLB IP Target 直接到 Pod 时，Client-IP Preservation 规则与 Target Group Attribute 另有差异。
English
For an NLB using NodePort and instance targets, externalTrafficPolicy: Cluster is the default. Any healthy node can receive traffic and forward it to any cluster endpoint, producing more even distribution, but cross-node forwarding can SNAT to a node address so the pod loses the original client IP. Local forwards only to endpoints on the ingress node, preserving the client source address and avoiding a hop, but nodes without local pods must not receive traffic and uneven placement can create hot spots. Evaluate health checks, topology spread, DaemonSet or replica placement, and traffic imbalance. NLB IP targets go directly to pods and have separate client-IP preservation and target-group attribute behavior.
Transcript
17:45 Now, before we close this lecture,
17:48 there is one more configuration I want to talk about
17:50 because we have seen the question around it
17:53 and that's how do you preserve the client IP address?
17:57 So when the client hits the load balancer
18:00 and ultimately it reaches the pod,
18:01 if application running in the pod or in a container wants
18:04 to know the client IP address, how should we do that?
18:08 Right? So let's look at that.
18:09 So there is external client, you have node,
18:12 you have kube-proxy on every node,
18:14 and then you have pods running on that node.
18:17 Now you could use NLB or ALB in case of EKS.
18:21 So if you're using NLB as a load balancer service,
18:25 in that case, you can set external traffic policy
18:28 as a specification for the service
18:30 and it defines the behavior of your traffic.
18:33 For example, if you say external traffic policy equal
18:37 to cluster, in that case, this kube-proxy here may send
18:41 the traffic to other nodes and the ports inside other nodes.
18:45 So it does proper load balancing across the node
18:49 if you have the external traffic policy equal
18:51 to cluster and that's the default policy
18:54 if you create the load balancer as a service with NLB.
18:57 So in this case, what happens, the traffic comes,
19:02 it goes to the kube-proxy, and now if there is a pod
19:06 for service B, it sends to that and as well
19:08 as this can send traffic to the port on another node.
19:12 But what happens in this case,
19:14 as the traffic goes to other node, the source IP
19:17 of the packet is replaced with this node source IP.
19:20 That means the port B here now can't see
19:22 the client IP address which originated the request.
19:25 And that's the problem.
19:26 That means you can't preserve the client IP.
19:29 The solution to that could be using
19:33 the external traffic policy equal to local.
19:35 Now what it means that traffic
19:37 is not routed outside of the node
19:39 and client IP address is propagated to the end ports.
19:42 So what happens, you have external traffic policy equal
19:46 to local, and the kube-proxy will only send
19:48 the traffic to the ports on the same node.
19:51 It won't send traffic to the port
19:52 which are not on that node.
19:54 So this is not done
19:56 and that's where port can see the client IP address.
19:59 But the problem here is
20:00 that the load balancing is not even, right?
20:03 So as much traffic you have, only these two ports
20:06 will receive that traffic.
20:08 This port will not receive that.
20:10 So again, there are pros and cons
20:11 and you need to see what works best for you.
10. ALB 通过 X-Forwarded-For 传递 Client IP，Application 必须安全解析 Proxy Header
时间范围：20:15–20:47
总结 / Summary
中文
ALB 是 HTTP Proxy，会终止并重新建立连接；Backend Socket 的 Peer 通常是 ALB/Target Path，而原始 Client IP 写入 X-Forwarded-For。Application/Framework 应只信任来自已知 ALB/Trusted Proxy 的 Header，并按 Proxy Chain 规则选择正确 Hop，防止外部 Client 伪造 Header。若需要 L4 Source IP、TLS Pass-through 或 Non-HTTP Protocol，应选择 NLB 并按 Target Type、Proxy Protocol v2、Client IP Preservation 与 externalTrafficPolicy 设计，而不是把 ALB Header 语义套用到所有流量。
English
An ALB is an HTTP proxy that terminates and re-establishes connections. The backend socket usually sees the ALB or target path as its peer, while the original client address is carried in X-Forwarded-For. Applications and frameworks must trust that header only from known ALBs or trusted proxies and select the correct hop in the proxy chain to prevent client spoofing. Workloads requiring Layer 4 source identity, TLS pass-through, or non-HTTP protocols should use NLB and design around target type, Proxy Protocol v2, client-IP preservation, and externalTrafficPolicy rather than applying ALB header semantics to every flow.
Transcript
20:15 So that's about the NLB.
20:16 In case of ALB, you know that HTTP header
20:19 X-Forwarded-For has the client IP address
20:21 and you can grab that IP address from this header.
20:24 So it is easy in that case.
20:27 Okay, so we'll stop here for this lecture.
20:28 I understand that it could be a little complex
20:31 putting all things together, but Kubernetes,
20:34 in general, is complex and unfortunately we can't
20:37 cover Kubernetes to the depth that we want to
20:40 and that's where probably you should focus only
20:41 on the networking part as of now.
20:43 So thanks for watching and stay tuned for the next lectures.
整讲总结 / Overall Summary
中文
EKS Service Exposure 是一条逐层抽象链：ClusterIP 提供 Cluster 内稳定 VIP/DNS；NodePort 在所有 Node 打开 Port；LoadBalancer Service 由 AWS Load Balancer Controller 通常创建 NLB；Ingress 作为独立 L7 Resource 创建/共享 ALB 并做 Host/Path Routing。Instance Target 走 NodePort，IP Target 直达 Pod。Client IP Preservation 取决于 NLB/ALB、Target Type、externalTrafficPolicy 与 Proxy Header，而不能只看 Service 名称。
English
EKS service exposure is a layered abstraction. ClusterIP provides a stable in-cluster VIP and DNS name; NodePort opens a port on every node; a LoadBalancer Service is normally reconciled by AWS Load Balancer Controller into an NLB; and Ingress is a separate Layer 7 resource that creates or shares an ALB for host and path routing. Instance targets use NodePort, while IP targets reach pods directly. Client-IP preservation depends on NLB or ALB behavior, target type, externalTrafficPolicy, and proxy headers, not merely the Service name.