kubernetes测试开发面试题二

原创已于 2024-12-11 00:27:40 修改 · 1.1k 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器 #云原生

于 2024-12-10 22:10:07 首次发布

一. 一个node资源可以计算出最大创建多少 pod，但是我们怎么知道 kubernetes可以管理多少POD，这个怎么判断？

Kubernetes 的能力不仅取决于单个节点的 Pod 数量上限，还涉及到控制平面（Control Plane）的能力，比如 API Server、Scheduler、Controller Manager 等组件的性能。以下是判断 Kubernetes 能够管理多少 Pod 的方法和考虑因素：

1. 影响 Kubernetes 管理 Pod 上限的因素

1.1 控制平面性能

API Server：每个 Pod 都需要 API Server 处理其创建、更新、删除等事件。
Scheduler：负责对每个未绑定的 Pod 进行调度。
Controller Manager：维护 Pod 的期望状态与实际状态一致。

1.2 节点容量

每个节点能创建多少 Pod 由节点资源（CPU、内存）和 Kubelet 的最大 Pod 数限制：
默认 Kubelet 限制为 110 Pods。
可以通过 --max-pods 参数调整：

kubelet --max-pods=250

1.3 网络插件

网络插件（如 CNI 插件）可能有性能瓶颈。例如：
每个 Pod 会分配一个网络接口，插件需要处理大量接口时可能变慢。
如 Flannel、Calico , nsxt等插件的限制。

1.4 存储插件

对存储的动态配置和挂载也会限制集群管理 Pod 的能力。

1.5 ETCD 的性能

ETCD 存储集群的所有状态信息。
ETCD 的写入延迟直接影响到集群扩展能力。

2. 测试 Kubernetes 最大可管理的 Pod 数量

2.1 性能测试工具

可以使用以下工具对 Kubernetes 的管理能力进行压力测试：

(1) Kubernetes Perf-Test

Kubernetes 官方提供的性能测试工具。
包括 ClusterLoader2，专门用于模拟大规模 Pod 和节点场景。

git clone https://github.com/kubernetes/perf-tests.git
cd perf-tests/clusterloader2

配置测试用例（YAML 文件）：定义模拟的 Pod 和节点数：

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
data:
  test.yaml: |
    phases:
    - replicas: 10000
      name: create-pods
      objectTemplatePath: pod-template.yaml

运行测试：
go run main.go --kubeconfig=/path/to/kubeconfig --testconfig=config.yaml
查看测试结果，判断最大负载能力。

(2) Kubemark

用于模拟大量节点和 Pod，不消耗实际资源。
具体用法参见面试1介绍的 Kubemark。

(3) Chaos Testing 工具

使用工具如 Litmus 或 Gremlin 进行压力测试。
在实际场景中不断增加 Pod 数量，观察系统的极限和响应能力。

2.2 理论计算

根据 Kubernetes 官方文档，一个 Kubernetes 集群的默认规模限制：

最大节点数：5000。
最大 Pod 数：每个节点 110，总计 ~15 万（5000 x 110）。
最大 Namespace 数：1 万。
最大 Service 数：1 万。
实际中，超出这些限制需要优化集群配置和组件性能。

3. 判断方法

3.1 观察控制平面负载

运行大量 Pod 后，监控控制平面的关键指标：

API Server：
etcd_request_duration_seconds：ETCD 的请求延迟。
apiserver_request_duration_seconds：API Server 的请求延迟。

Scheduler：
scheduler_e2e_scheduling_duration_seconds：调度时间。
scheduler_pending_pods：挂起的 Pod 数量。

Controller Manager：
观察事件处理队列是否有积压。

当这些指标接近瓶颈时，可以判断管理能力的上限。

3.2 模拟 Pod 部署

通过脚本创建大量 Pod，观察集群行为：

for i in {1..100000}; do
  kubectl run pod-$i --image=nginx --restart=Never -- sleep 3600
done

使用 kubectl get pods 查看所有 Pod 的状态。
使用 kubectl top nodes 检查节点的资源使用情况。

3.3 异常检测

当集群达到管理极限时，可能会观察到以下现象：

API Server 响应变慢或请求超时。
Scheduler 出现调度队列积压。
ETCD 的读写延迟显著增加。
Pod 状态卡在 Pending 或调度失败。

4. 提高 Kubernetes 可管理的 Pod 上限

1) 优化 ETCD：

升级 ETCD 版本。
扩展 ETCD 集群。
调整 ETCD 的存储配置。

2) 优化 API Server 和 Scheduler：

增加副本数。
调整 API Server 的缓存和速率限制。
使用优先级调度（Priority Scheduling）。

3) 调整节点配置：

增加 --max-pods 限制。
减少每个 Pod 的资源请求（如 CPU 和内存）。

4) 使用虚拟节点：

利用 Virtual Kubelet 增加虚拟节点。

5) 分片集群：

使用工具如 KubeFed 管理多个 Kubernetes 集群。

5. 总结

通过性能测试工具和监控系统指标，可以评估 Kubernetes 的管理能力上限，同时通过调整配置提升性能，确保集群在高负载下稳定运行。

二. 性能测试工具：Kubernetes perf-test使用指南

Kubernetes Perf-Test 是官方提供的性能测试工具，用于评估 Kubernetes 集群的性能，包括集群扩展能力、API Server 吞吐量、调度器性能等。以下是详细使用步骤：

1. 准备工作

1.1 环境要求

一个可访问的 Kubernetes 集群。
配置好的 kubectl 和集群凭据。
Golang 环境（建议版本 >= 1.18）。

1.2 克隆 Perf-Test 仓库

git clone https://github.com/kubernetes/perf-tests.git
cd perf-tests/clusterloader2

2. 配置测试环境

2.1 配置文件说明

Perf-Test 使用 YAML 文件配置测试场景，包括：

模拟的 Pod 数量。
命名空间数量。
对象类型（如 Deployment、Service）。
测试持续时间。

(1) 配置文件路径

测试用例配置文件位于 config/testing 文件夹中：
示例配置文件：
bash config/testing/load/config.yaml（负载测试）。 config/testing/throughput/config.yaml（吞吐量测试）。

(2) 示例配置文件

以下是一个简单的配置文件示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
data:
  test.yaml: |
    name: "basic-load-test"
    phases:
      - replicas: 1000
        objectTemplatePath: pod-template.yaml
        namespaceRange:
          min: 1
          max: 10
    tuningSets:
      - name: "uniform"
        qpsLoad:
          qps: 100
          burst: 200

(3) 模板文件

objectTemplatePath 指向对象模板（如 Pod、Deployment 等），位于 templates 文件夹。
示例 Pod 模板：

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  labels:
    app: test
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]

3. 运行测试

3.1 启动测试

使用以下命令运行性能测试：

go run cmd/clusterloader.go --kubeconfig=/path/to/kubeconfig --testconfig=config/testing/load/config.yaml
参数说明：
--kubeconfig：指向集群的 kubeconfig 文件。
--testconfig：指向测试用例配置文件路径。

4. 查看测试结果

4.1 输出日志

运行测试后，Perf-Test 会输出以下日志信息：

各阶段的测试进度。
API Server 的响应时间。
Pod 创建和调度状态。

4.2 测试结果存储路径

测试完成后，结果会存储在本地文件夹 ./results 中。结果包括：

各阶段测试的统计信息。
指标和延迟分析数据。

4.3 常见指标

以下是 Perf-Test 常用的测试指标：

1) Pod 创建时间：

平均时间：API Server 从接收到 Pod 创建请求到 Pod 被调度完成的时间。

2）调度延迟：

调度器为未绑定的 Pod 分配节点的时间。

3）API Server 吞吐量：

每秒处理的请求数量。

4）系统负载：

节点资源使用情况。

5. 调优集群性能

通过分析测试结果，可以针对性能瓶颈进行优化：

1. API Server：

增加副本数。
调整 QPS 和并发限制（–max-requests-inflight）。

2. Scheduler：

优化调度器策略（如优先级和抢占）。
增加调度器实例。

3. ETCD：

使用更快的存储（如 SSD）。
扩展 ETCD 集群规模。

4. 节点配置：

增加节点数或节点资源。
调整 Kubelet 参数（如 --max-pods）。

6. 高级用法

6.1 自定义测试用例

创建自定义配置文件：
定义新的 YAML 配置文件，指定更多复杂的测试场景（如多层 Deployment、混合负载）。
示例：

name: "complex-test"
phases:
  - replicas: 500
    objectTemplatePath: deployment-template.yaml
    namespaceRange:
      min: 1
      max: 5
  - replicas: 100
    objectTemplatePath: service-template.yaml
    namespaceRange:
      min: 1
      max: 5

6.2 多用户并发测试

配置 tuningSets 来控制负载强度：

tuningSets:
  - name: "high-concurrency"
    qpsLoad:
      qps: 500
      burst: 1000

6.3 集成 Prometheus

将测试结果导入 Prometheus，实时监控指标。

7. 注意事项

控制平面资源分配：

测试可能会让控制平面组件（如 API Server、Scheduler）达到瓶颈。
监控 CPU 和内存消耗，避免过载。

测试环境隔离：

在测试时，避免与生产集群共用资源，防止影响生产环境。

合理配置 QPS：

测试负载过高可能导致测试数据失真。逐步提高 QPS，以找到系统的实际瓶颈。
通过 Kubernetes Perf-Test 工具，可以快速评估集群在不同负载条件下的表现，并通过优化集群配置，进一步提升 Kubernetes 的扩展性和性能。

三. 使用 Litmus 进行 Kubernetes 压力测试

Litmus 是一个开源的混沌工程工具，专注于测试 Kubernetes 集群的可靠性和稳定性。它通过注入混沌场景**（如节点压力、Pod 崩溃）**来评估系统在极端条件下的表现。

1.1 安装 Litmus

安装 kubectl 和 Helm 确保集群已安装 kubectl 和 helm。
通过 Helm 安装 Litmus

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update
helm install litmus litmuschaos/litmus

验证安装查看 Litmus 的控制台和服务：

kubectl get pods -n litmus

1.2 创建压力测试

选择混沌实验 Litmus 提供多种实验，适用于不同的压力测试场景：

Node CPU Hog：增加节点 CPU 使用率。
Node Memory Hog：增加节点内存使用率。
Pod Delete：随机删除 Pod。

定义实验配置创建一个混沌实验 YAML 文件，例如：

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: node-cpu-hog
  namespace: default
spec:
  appinfo:
    appns: default
    applabel: "app=nginx"
  chaosServiceAccount: litmus
  experiments:
    - name: node-cpu-hog
      spec:
        components:
          env:
            - name: CPU_CORES
              value: "2"  # 消耗的核心数
            - name: TOTAL_CHAOS_DURATION
              value: "60"  # 实验持续时间（秒）

运行实验应用配置启动混沌实验：

kubectl apply -f node-cpu-hog.yaml
监控实验使用以下命令查看实验状态：

kubectl get chaosengine
kubectl describe chaosengine node-cpu-hog

分析结果查看实验日志并监控集群资源：

kubectl logs -f <chaos-pod-name> -n litmus
kubectl top nodes

1.3 优化和清理

根据实验结果，优化集群配置或应用资源。
删除实验相关资源：
kubectl delete chaosengine node-cpu-hog

四. 使用 Gremlin 进行 Kubernetes 压力测试

Gremlin 是一个商业化混沌工程平台，支持在云、容器和裸机环境中运行故障注入实验。它适用于更细粒度的压力测试和自动化。

2.1 安装 Gremlin

创建 Gremlin 账号注册并登录 Gremlin 官方网站。
安装 Gremlin DaemonSet

获取 Gremlin Team ID 和 Secret。
在 Kubernetes 集群中安装 Gremlin：

kubectl apply -f https://downloads.gremlin.com/kubernetes/gremlin-latest.yaml

编辑 DaemonSet，添加凭据：

env:
- name: GREMLIN_TEAM_ID
  value: "<your-team-id>"
- name: GREMLIN_TEAM_SECRET
  value: "<your-team-secret>"

验证安装检查 Gremlin Agent 是否运行正常：
kubectl get pods -n gremlin

2.2 创建压力测试

登录 Gremlin Web 控制台。
选择目标集群。

选择实验类型 Gremlin 提供以下压力测试类型：

CPU Attack：消耗指定容器或节点的 CPU。
Memory Attack：占用节点或容器的内存。
Network Attack：模拟网络延迟、丢包等场景。
Pod Kill：随机终止 Pod。

运行实验

选择目标节点或容器。
配置实验参数（如 CPU 使用率、时间）。
点击 Start 开始实验。

监控和验证

在 Gremlin 控制台查看实验进度和结果。
在 Kubernetes 中监控资源使用：

kubectl top nodes
kubectl get pods

2.3 命令行运行实验

Gremlin 提供 CLI 工具，可以直接在命令行中运行实验：
gremlin attack-container --target <container-name> --attack-type cpu --cpus 2 --duration 60

2.4 实验完成后恢复

Gremlin 的实验不会永久影响系统，可通过控制台或 CLI 停止实验。
查看恢复后的集群状态，确保资源恢复正常。

五. Litmus 与 Gremlin 对比

特性	Litmus	Gremlin
性质	开源免费工具	商业化工具（有免费试用版）
安装	轻量级，使用 Helm 安装	需要注册和配置 DaemonSet
实验类型	适用于 Kubernetes 混沌测试	支持更多类型（网络、容器、裸机）
用户界面	CLI 和 YAML 驱动	图形界面和 CLI
适用场景	Kubernetes 专属	Kubernetes 和非 Kubernetes 环境
学习曲线	较陡峭（需要熟悉 Kubernetes 原理）	平缓（Web 界面友好）