动态扩缩容主要包括两个层级的动态扩缩容。一个层级是应用本身级别的扩缩容，如HPA、VPA。当应用负载过高时，可以通过HPA多部署几个Pods副本；或者通过VPA对当前Pod硬件资源进行扩容，以此来减少应用负载。 另一层是对集群自身的扩容，如 worker 节点的扩容。如部署Pods应用时，如果出现无可用节点资源可用时，则通过 Cluster Autoscaler 加入一些新的节点，并在新节点上重建Pods。 本文主要看一下应用这个层级的扩缩容方案。 水平扩展HPA && 垂直扩展VPA HPA 在 Kubernetes 中，HPA(HorizontalPodAutoscaler)也称为水平扩缩容，它将根据当前应用程序工作负载，自动更新工作负载资源 （例如 Deployment 或者 StatefulSet）以满足当前需求。简单讲的话，就是如果集群检测到当前应用程序的n个Pod负载如果比较高的话，就再创建几个Pod副本，以减少当前负载，也就是我们平时说的水平扩容。相反如果应用程序Pod负载比较低的话，则将Pod副本数量进行减少，节省服务器资源，这个就是水平缩容。 它的工作原理是这样的，集群控制器会定期（默认每 30 秒）查询目标资源的 Pod 的资源使用情况，并将其与 HPA 对象中指定的指标进行比较。如果资源使用情况超过或低于目标指标，HPA 控制器会根据扩缩容策略来扩缩容 Pod 数量。 Kubernetes 默认支持根据容器的 CPU 和内存的使用率。拿下面例子来说 apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: web-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-app minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu targetAverageUtilization: 80 这里 scaleTargetRef 表示要操作的 Kind 对象 Deployment，其中副本最小数量为1，最大为10。而对条件的定义就是 metrics字段，这个示例里只指定了CPU，表示当 CPU 平均使用率达到80% 的时候就开始扩容。

Kubernetes 中的 overlay 网络和 underlay 网络是两个不同的网络层面。 Underlay 网络 在 Kubernetes 网络架构中，Underlay 网络是指承载 Kubernetes 网络流量的物理网络或底层网络。这个网络通常由物理交换机、路由器和其他网络硬件组成，它们之间通过各种路由协议（例如 OSPF、BGP 等）连接在一起组成的传统网络。 Underlay 网络负责为 Kubernetes 节点提供基本的网络连接，它为上层的 overlay 网络提供支持。 总之，Kubernetes 的网络流量，例如 Pod 到 Pod、Pod 到 Service 等都将在这个 Underlay 网络上进行传输。 Overlay 网络 对于 Overlay 网络也被称为 覆盖网络，想必只要接触过一点 kubernetes 网络知识的同学都不陌生，它主用来解决 不同节点 中 Pod 之间通讯的一种网络解决方案。 在上图可以看到 Overlay 网络是构建在 underlay 网络之上的一层虚拟网络，它通过封装数据包（如VXLAN）通过物理网络进行传输，到达目标网络后再对数据包进行解包得出真正的目标地址，最后响应数据包原路返回，从而实现跨网段的网络通讯。 它就像创建了一个逻辑网络，可以实现跨越不同节点和集群实现网络正常通讯，但有一个前提是对于 overlay 网络要求节点网络三层互通。对于 overlay 不好的一点是存在封装、解封装过程，带来一定性能损耗，也因此各大云厂商均大力发展 underlay容器网络，使得容器网络具有直通能力，比如ELB直通容器，容器直接绑eip等。 常见的 overlay 网络有 Flannel、Calico、Weave 等。 总之，Overlay 网络为 Kubernetes 集群中的 Pod 提供 IP 地址,并实现 Pod 之间的通信。

当我们想将 k8s 集群里的服务向外暴露时，一般是将 k8s service 指定 LoadBalancer类型。目前大多数云厂商会绑定云平台的负载均衡器，并为其分配一个固定的公网 IP 从而向外提供服务。而对于我们自建的 kubernetes 裸机集群则只能选择类似 MetalLB 这类解决方案，这种情况下如何让用户可以通过这个 IP 访问到自建 k8s 的服务呢，本文来分析一下其实现原理。 本文的环境安装了 MetallB，它指定分配 IP Pool 为内网 IP 地址，实验环境为 https://blog.haohtml.com/posts/install-kubernetes-in-raspberry-pi/。 将外部请求流入集群节点 当我们需要访问一台机器时,无论是使用 IP 地址还是域名,最终都需要将其解析为 IP 地址。而要真正建立连接并传输数据,我们必须获取目标 IP 地址对应的 MAC 地址,这是由于 TCP/IP 协议分层机制决定的。 在 TCP/IP 协议栈的链路层,数据是通过封装成数据帧的方式在局域网内传输的。数据帧中包含了目标 MAC 地址,用于标识应该将数据发送到哪个网络设备。因此,如果我们想要与某台机器建立通信,就必须首先知道其 IP 地址对应的 MAC 地址。 而 ARP 协议正是解决这一问题的利器。它通过在局域网内广播 ARP 请求,询问拥有某 IP 地址的主机的 MAC 地址。拥有该 IP 地址的目标主机会作出 ARP 响应,将自身的 IP 地址和 MAC 地址映射关系回复给发送方。发送方就可以基于这个映射关系,构建含有正确目标 MAC 地址的数据帧,并最终通过物理网络将数据传输到目的地。 搞明白了一点，理解起来就简单多了。 这里先贴一下实验环境，k8s master 节点 ip 配置

这里是 arm64 架构，树莓派 4B, 四核八 G 内存 配置，系统为 Ubuntu 22.04.1 LTS $ uname -a Linux ubuntu 5.15.0-1049-raspi #52-Ubuntu SMP PREEMPT Thu Mar 14 08:39:42 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux $ cat /etc/issue Ubuntu 22.04.1 LTS \n \l 环境检查 由于 k8s 会使用 8080 和 6443 这两个端口，因此要保证端口可用，然后禁用 swap。 sudo swapoff -a 最后对安装环境初始化，参考 https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/ 安装 Docker 参考 https://docs.docker.com/engine/install/ubuntu/ 安装成功后，修改 cgroupdriver 为 systemd，同时为了国内访问 docker 镜像加速，需要设置一下 aliyun 的 docker 镜像地址 sudo tee /etc/docker/daemon.json <<-'EOF' { "exec-opts": ["native.

在做一个试验时，无意中发现使用 kubectl create service 命令无法为一个通过 deployment 创建出来的pod创建对应的 service， 感觉有点奇怪，经过分析才明白怎么回事，这里将过程记录一下。 这里需要说明一下，本文操作全部是通过 kubectl create 命令来完成的，并没有使用 kubectl apply -f pod.yaml 这种方式。 这里先创建一个实验命名空间 lab $ kubectl create ns lab 首先创建一个deployment 对象 $ kubectl create deployment test --image=nginx:1.23-alpine --replicas=2 --port=80 -n lab 确认创建成功 $ kubectl get deploy,pod -n lab NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/test 2/2 2 2 16s NAME DESIRED CURRENT READY AGE replicaset.apps/test-8544f5598b 2 2 2 16s NAME READY STATUS RESTARTS AGE pod/test-8544f5598b-7tfq4 1/1 Running 0 16s pod/test-8544f5598b-d48js 1/1 Running 0 16s 这里我们成功创建了一个 test的 deployment 对象，而由此创建的 Pod.