kubernetes 测试开发面试题三

🕗 发布于 2024-12-11 07:32 kubernetes 容器云原生

一、kubernetes cluster部署好之后，我们如何知道这个集群是好的，可用的？

要验证 Kubernetes 集群是否部署成功并处于可用状态，可以通过以下步骤逐步检查和测试集群的健康状况。

1. 基础验证

1.1 确保所有节点都处于 Ready 状态。

kubectl get nodes

NAME          STATUS   ROLES    AGE    VERSION
node-1        Ready    master   5m     v1.28.0
node-2        Ready    worker   5m     v1.28.0

如果节点状态为 NotReady 或 Unknown，需要检查节点的连接、Kubelet 和网络配置。

1.2 检查核心组件 kube-apiserver、kube-scheduler、kube-controller-manager 是否正常运行。

kubectl get pods -n kube-system
输出示例：

NAME                                     READY   STATUS    RESTARTS   AGE
kube-apiserver-node-1                    1/1     Running   0          5m
kube-controller-manager-node-1           1/1     Running   0          5m
kube-scheduler-node-1                    1/1     Running   0          5m
etcd-node-1                              1/1     Running   0          5m

核心组件应该处于 Running 状态，且 RESTARTS 不应过高。

1.3 测试集群 API是否响应

kubectl version --short
输出示例：

Client Version: v1.28.0
Server Version: v1.28.0

2. 网络验证

2.1 测试 Pod 间是否正常通信

部署一个简单的网络工具（如 nginx 和 busybox），测试 Pod 之间的通信。

kubectl run nginx --image=nginx --restart=Never
kubectl run busybox --image=busybox --restart=Never -- sleep 3600
kubectl exec -it busybox -- ping nginx

确保 Pod 之间可以正常通信。

2.2 测试服务访问-----部署一个 Service 并验证访问：

kubectl expose pod nginx --port=80 --target-port=80 --type=ClusterIP
kubectl run curl --image=appropriate/curl --restart=Never -- curl nginx:80

应该能成功返回 nginx 的默认页面。

3. 存储验证

3.1 测试 PersistentVolume

创建一个 PVC 并绑定到 Pod。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

kubectl apply -f pvc.yaml
kubectl describe pvc test-pvc

确保 PVC 状态为 Bound。

3.2 测试PVC 绑定的 Pod 测试读写操作。

4. 应用验证

4.1 部署示例应用—部署一个多容器应用（如 guestbook）。

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml

确保应用所有 Pod 都处于 Running 状态。

4.2 测试负载均衡

创建 LoadBalancer 类型的 Service，并从外部访问应用。

kubectl expose deployment frontend --type=LoadBalancer --name=frontend-lb --port=80

访问分配的 LoadBalancer 地址，验证前端页面是否正常工作。

5. 性能与压力测试

5.1 node, pod 资源使用情况

使用以下命令监控节点和 Pod 的资源使用情况：

kubectl top nodes
kubectl top pods

5.2 简单负载测试

部署工具如 Apache Bench (ab) 或 Siege，模拟流量并观察集群的表现。

6. 日志与监控

6.1 检查日志

查看核心组件的日志以捕获任何潜在问题：

kubectl logs -n kube-system <component-name>

6.2 启用监控工具

配置 Prometheus 和 Grafana，实时监控集群的性能和资源消耗。

7. 总结：验证结果

验证条件
集群被视为可用时满足以下条件：

所有节点状态为 Ready。
核心组件运行正常且稳定。
Pod 间网络通信正常。
存储功能可用。
服务暴露和负载均衡正常工作。
部署的实际应用能正常运行。
资源监控未发现明显瓶颈。

通过上述步骤和测试，可以全面验证 Kubernetes 集群是否处于健康可用状态，并为生产部署做好准备。

二、kubernetes有哪些功能

Kubernetes 是一个强大的容器编排平台，提供了广泛的功能来管理容器化应用。以下是 Kubernetes 的主要功能分类及其核心特性：

1. 集群管理

1.1 节点管理

自动节点注册：新节点可以自动加入集群。
节点健康检查：监控节点的健康状态，自动标记 Ready 或 NotReady。
节点伸缩：支持动态扩展或缩减集群节点数（如与云提供商结合的自动扩展）。

1.2 资源分配与调度

智能调度器：根据资源需求、节点容量、优先级等因素，智能选择最佳节点运行 Pod。
资源预留：支持为 Pod 设置 CPU、内存等资源请求和限制。
亲和性与反亲和性：定义 Pod 之间的部署规则（如强制一起部署或避免部署在同一节点上）。

2. 应用管理

2.1 工作负载类型

Deployment：用于无状态应用的部署和管理。
StatefulSet：管理有状态应用，如数据库或需要固定名称的服务。
DaemonSet：确保每个节点上运行一个 Pod（例如日志收集器）。
Job 和 CronJob：处理一次性任务或定时任务。

2.2 应用编排

滚动更新：逐步替换旧版本的应用，确保零停机。
回滚：在更新失败时自动回退到之前的版本。
蓝绿部署与金丝雀部署：通过策略实现更灵活的发布流程。

3. 服务发现与负载均衡

DNS 集成：每个 Service 都会分配一个 DNS 名称，供 Pod 间通信使用。
负载均衡：
- ClusterIP：集群内部的负载均衡。
- NodePort：通过节点 IP 和端口暴露服务。
- LoadBalancer：基于云平台的外部负载均衡器。
服务发现：通过 Kubernetes 内置的机制发现和访问服务。

4. 网络与通信

Pod 间通信：每个 Pod 都有一个唯一的 IP，支持直接通信。
跨节点通信：通过网络插件（如 Flannel、Calico）实现。
网络策略：基于规则控制 Pod 之间和 Pod 与外部的通信。
Ingress 控制器：用于管理外部访问（如 HTTP、HTTPS）的路由规则。

5. 存储管理

持久化存储（Persistent Storage）：
- 支持多种存储后端（如 NFS、Ceph、AWS EBS）。
- 使用 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）抽象存储资源。
动态存储分配：通过 StorageClass 自动创建 PV。
数据迁移：支持在不同节点间移动数据卷。

6. 自动化和弹性扩展

自动扩展：
- Pod 水平自动扩展（HPA）：根据负载动态调整 Pod 数量。
- 集群自动扩展：根据需求动态增加或减少节点数。
自愈能力：
- 自动重启失败的 Pod。
- 替换状态不健康的节点或 Pod。
- 重新调度资源不足的 Pod。

7. 安全性

认证与授权：
- 支持多种身份认证方式（如证书、令牌、OIDC）。
- 基于 RBAC（角色权限控制）的权限管理。
网络安全：
- 网络策略控制 Pod 之间的通信。
机密管理：
- 使用 Secret 和 ConfigMap 管理敏感信息和配置信息。
Pod 安全策略(PSP)：限制 Pod 的权限，如禁止特权模式。

8. 日志与监控

日志管理：
- 提供 kubectl logs 查看 Pod 日志。
- 集成 Fluentd 等工具将日志收集到集中式存储。
监控：
- 通过 Metrics Server 提供资源监控数据（如 CPU、内存使用）。
- 集成 Prometheus、Grafana 等工具实现高级监控和可视化。
- 事件追踪：记录集群中的事件（如 Pod 创建、调度、失败）。

9. 扩展性

API 和自定义资源：
- 提供 RESTful API 接口。
- 支持 CRD（Custom Resource Definition），允许用户扩展 Kubernetes 的功能。
控制器扩展：通过 Operator 实现更复杂的自动化任务（如数据库管理）。
插件系统：
- CNI（网络插件）：如 Flannel、Calico、WeaveNet。
- CSI（存储插件）：如 AWS EBS、GCE Persistent Disk。
- 容器运行时接口（CRI）：支持 Docker、Containerd、CRI-O。

10. 社区支持与工具生态

工具支持：
- Helm：用于应用的打包和部署。
- Kustomize：支持原生 YAML 配置管理。
社区活跃：定期发布新版本，支持多种部署方式（如 kubeadm、kops、minikube）。
通过这些功能，Kubernetes 成为管理容器化应用的强大工具，能够简化部署、提高可用性、增强弹性扩展能力，适用于从开发到生产环境的广泛场景。

三、物理资源测试 vs. Kubemark 测试：对比、优缺点

1. 定义

物理资源测试
- 定义：直接在真实的物理硬件和节点上运行 Kubernetes 集群，利用实际资源（CPU、内存、网络）进行测试。
- 应用场景：用于评估生产环境的性能、稳定性和可扩展性。
Kubemark 测试
- 定义：一种 Kubernetes 集群模拟工具，用于创建虚拟节点（Hollow Nodes）以模拟大规模集群负载，而无需实际分配大量物理资源。
- 应用场景：适合进行大规模扩展性测试，在资源受限的情况下评估控制平面的能力。

2. 对比

特性	物理资源测试	Kubemark 测试
资源依赖	需要真实的物理节点和硬件资源	仅需要少量资源即可模拟大规模集群
测试规模	受限于硬件资源	可轻松模拟数千个节点、数万个 Pod
测试精度	真实环境，测试结果接近生产情况	虚拟环境，可能存在部分偏差
网络测试	包括真实网络延迟、吞吐等	模拟网络通信，可能无法完全反映真实情况
控制平面压力	与生产环境一致，全面评估控制平面性能	专注于测试控制平面的可扩展性
成本	高成本，需投入大量物理资源	成本较低，充分利用虚拟化技术
调试和诊断	直接观察真实环境中的问题	更适合调试控制平面，节点级问题不易复现
适用场景	用于生产环境性能验证或资源利用优化	适合进行大规模负载测试和控制平面评估

3. 优缺点

3.1 物理资源测试

优点
- 真实结果：测试环境与生产一致，结果具有更高可信度。
- 全面性：可以测试所有组件（如网络性能、存储 IO）和应用工作负载。
- 硬件限制验证：能够识别硬件瓶颈（如磁盘 IO、CPU 性能等）。
缺点
高成本：需要大量物理资源，特别是在模拟大规模集群时。
扩展性受限：物理节点数量限制了测试规模。
调试复杂：真实环境中问题可能受到多个外部因素影响，调试难度增加。

3.2 Kubemark 测试

优点
- 低成本：无需大量硬件资源，通过模拟节点进行大规模测试。
- 高扩展性：可以轻松模拟数千节点和数万个 Pod 的场景。
- 控制平面专注：专注于测试控制平面的扩展能力（如调度性能、API Server 吞吐量）。
- 快速测试：部署和运行速度快，便于频繁进行大规模测试。
缺点
- 缺乏真实感：无法模拟真实的物理硬件性能、网络延迟和 IO。
- 结果偏差：因为 Hollow Node模拟的负载是理想化的，无法完全代表真实节点。
- 功能覆盖有限：主要用于控制平面压力测试，对数据平面（如网络、存储）的测试能力较弱。
- 依赖经验配置：需要调整 Hollow Node 的负载模拟参数以贴近实际情况。

4. 选择依据

4.1 选择物理资源测试

如果需要：

真实环境的性能基准测试。
测试网络性能、存储 IO 或硬件相关性能。
验证应用在生产环境的表现。

4.2 选择 Kubemark