介绍 K8S 的 HorizontalPodautoscaler（HPA）用于根据实际负载，动态地调整 workload 资源的 pod 数量，比如 Deployment、StatefulSet 等。 一个实际的例子可以参考：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/ HPA 的工作流程是： 找到目标 → 选出 Pod → 获取指标 → 求平均 → 算比例 → 推导副本数 找到目标 在 HPA 中设置 scaleTargetRef 用于找到目标对象： spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app 然后读取该对象的 .spec.selector，找出所有匹配的 pod。 因此我们也可以发现，HPA 并不是直接管理 Pod，而是通过 Deployment/StatefulSet 的 selector 间接管理。 获取指标 指标有三种来源： Pod 资源指标，比如内存、CPU Pod 自定义指标，比如每个 Pod QPS 外部指标，比如某个 Ingress 的总 QPS、kafka topic lag 计算副本数 计算每个目标 pod 的指标，比如 CPU 利用率 ...

Ingress 已成为过去 上一节说了 Ingress，k8s 已经停止在这个资源上开发新的特性了，已经是 archived / stable 的一种资源类型。相比 Ingress，官方目前推荐使用 Gateway API 来做流量路由。但 Gateway API 不是简单意义上的 Ingress 平替，而是 Kubernetes 官方规划的、用来逐步替代 Ingress 的下一代流量入口 API。 为什么 Ingress 已经走到了尽头？大致有以下几点原因： Ingress 同时承担流量入口、路由规则、TLS、Controller 选择、厂商扩展等功能，结果是 annotation 爆炸、不同 Controller 行为不一致等 Ingress 是单一资源，无法拆分职责，比如由平台团队控制入口（端口 / LB），由业务团队只配路由 主要还是因为 Ingress 这个资源本身的可扩展性/结构性问题，所有高级能力只能塞进 annotation，同一个 annotation 在不同 Controller 中语义不同 Gateway API 的设计 Gateway API 包含四种资源类型，分别是 GatewayClass、Gateway、HTTPRoute、GRPCRoute。 GatewayClass 类似 IngressClass，是 controller 与 gateway 之间的桥梁。GatewayClass 中通过 controllerName 指定了一个 gateway 控制器： apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: example-class spec: controllerName: example.com/gateway-controller Gateway 定义流量入口端点。Gateway 通过绑定一个 GatewayClass 来指定 controller，然后通过 HTTPRoute / GRPCRoute 将不同的路由规则及其 backend 绑定到 Gateway 上。举个例子，下面的 Gateway 在 80 端口监听 HTTP 请求（address/hostname 没有指定，由 controller 分配）： ...

Ingress 是什么 Ingress 是 Kubernetes 中的 L7(应用层，HTTP/HTTPS)反向代理与路由入口。 上一篇介绍了 Service，它与 Ingress 的区别是，Service 负责 L4（传输层，TCP/UDP）集群内部服务发现与负载均衡，Ingress 负责 L7 路由、域名/路径转发，他们一般配合着来使用： 用户请求 → Ingress → Service → Pod Ingress 这个 k8s 资源只是定义了路由规则，真正做反向代理的是 Ingress Controller。虽然 Ingress 是内置的资源，但 Ingress Controller 不是 k8s 内置的 contorller，而是可以根据需求自由选择的。比如官方维护的 ingress-nginx 和 aws-load-balancer-controller，还有第三方的 traefik 等，因此单纯创建 Ingress 并没有任何效果，还需要安装一个 Ingress Controller。 要注意，Ingress 只处理 L7 的协议（只支持 HTTP/HTTPS），创建一个 Ingress 并不会对外暴露任何端口，对外暴露端口是 NodePort 或 LoadBalancer 类型 Service 的工作。 Ingress 资源 一个最简单 Ingress 作为入门： apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: minimal-ingress spec: ingressClassName: nginx rules: - http: paths: - path: /testpath pathType: Prefix backend: service: name: test port: number: 80 在说 ingressClassName 字段之前先要介绍下 IngressClass 这个资源类型。一个集群中可以同时运行不同的 Ingress Controller。Ingress 将会选择其中一个 Ingress Controller 来处理，但它并不是直接指定 Controller 的名称或者是什么特殊的 id，而是通过 IngressClass 这个资源。IngressClass 绑定了一个特定的 Ingress Controller。比如下面的 IngressClass 绑定了 nginx ingress controller： ...

虚拟 IP 和服务代理 每个 k8s 节点上都运行了一个 kube-proxy，kube-proxy 以 pod 形式存在。 kube-proxy 与 Service 息息相关，可以说 Service 负责定义规则，而 kube-proxy 则在节点上具体实现由 Service 指定的规则。具体地，kube-proxy 监听 Service 和 EndpointSlice 资源的更新，并配置节点上相应的路由规则。 有人会问，为什么不用 DNS，配置多条 A 记录，结合 round-robin 等负载均衡算法来自动将虚拟 IP 的请求分发到真实 IP 上。原因是： DNS 很可能不遵守 A 记录的 TTLs（Time to live），导致真实 IP 发生变化时不能及时感知； 有些 APP 可能只访问 DNS 一次，但 DNS 可能会将这条记录永久保存； 即使 DNS 遵守 TTLs 配置，然后为了及时感知变化，TTLs 配置得很低的话，可能导致 DNS 负载变得很高。 kube-proxy 的代理模式 kube-proxy 不做实际的包转发，而是根据从 apiserver 监听 Service 与 EndpointSlice 的变化，并维护节点上的包处理规则，比如配置 iptables 规则、ipvs 规则等，最终由内核来完成真实流量的转发。 ...