K8s on NOSAE

K8S的HorizontalPodAutoscaler

Sun, 15 Feb 2026 21:24:54 +0800

介绍

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 利用率

K8S的GatewayAPI

Sun, 14 Dec 2025 00:39:29 +0800

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 分配）：

K8S的Ingress

Mon, 08 Dec 2025 22:24:11 +0800

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：

K8S的Service

Fri, 05 Dec 2025 23:45:16 +0800

虚拟 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 规则等，最终由内核来完成真实流量的转发。