请分享你的Kubernetes(K8s)使用经验，包括部署、管理等方面

能力考察点

这个问题主要考察面试者对Kubernetes的实际应用经验，包括：

• K8s核心概念的理解
• 实际部署经验
• 集群管理能力
• 故障排查经验
• 最佳实践的应用
• 自动化部署和CI/CD集成

答题思路

1. 首先介绍自己的K8s经验背景和使用时长
2. 详细说明在K8s部署方面的经验，包括：
   • 集群搭建方式
   • 应用部署策略
   • 配置管理
   • 网络和存储配置
3. 分享在K8s管理方面的经验，包括：
   • 日常运维
   • 监控和日志
   • 扩容和缩容
   • 故障排查
4. 提及一些实际项目案例和挑战
5. 分享最佳实践和经验教训
6. 总结K8s带来的价值和未来学习方向

答题示例

作为一名有3年Kubernetes使用经验的运维工程师，我会这样回答：

K8s经验背景

我有3年Kubernetes使用经验，从1.15版本开始使用，目前主要维护1.22-1.25版本的集群。我负责管理包含20多个节点、运行超过200个容器的生产环境集群，支持公司核心业务系统。

K8s部署经验

集群搭建

我使用过多种方式搭建K8s集群：

1. 云平台托管服务：在AWS上使用EKS，阿里云上使用ACK，这种方式最简单，云厂商负责控制平面管理。
2. kubeadm：在自建IDC环境中使用kubeadm搭建高可用集群，配置了多master节点和etcd集群。
3. 二进制部署：早期为了深入理解K8s组件，尝试过完全手动部署各组件。

# 使用kubeadm初始化控制平面节点的示例
kubeadm init --control-plane-endpoint="LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16

应用部署策略

在应用部署方面，我主要采用以下策略：

1. 声明式部署：使用YAML文件定义所有资源，通过Git进行版本控制。
2. Helm Charts：为复杂应用创建Helm Charts，实现应用打包和版本管理。
3. 渐进式交付：使用金丝雀发布和蓝绿部署策略降低发布风险。

# 一个典型的Deployment示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: myapp:v1.2.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

配置管理

在配置管理方面，我主要使用：

1. ConfigMaps：管理非敏感配置信息
2. Secrets：管理敏感数据，并配合使用Sealed Secrets或Vault进行加密
3. 自定义资源定义(CRD)：为特定应用创建自定义配置资源

# ConfigMap示例
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: production
data:
  database_url: "jdbc:postgresql://db:5432/appdb"
  log_level: "INFO"
  feature_flags: "feature1,feature2"

网络和存储配置

1. 网络：

   • 使用Calico作为CNI插件，支持网络策略
   • 配置Ingress Controller(Nginx)管理外部访问
   • 使用Service Mesh(Istio)管理微服务间通信

2. 存储：

   • 使用StorageClass动态配置PV
   • 针对有状态应用使用StatefulSet和PVC
   • 配置分布式存储解决方案(如Rook/Ceph)

# StorageClass示例
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

K8s管理经验

日常运维

1. 资源管理：

   • 使用Resource Quota和Limit Range限制命名空间资源使用
   • 定期检查和优化资源请求和限制
   • 使用HPA(VPA)实现自动扩缩容

2. 集群维护：

   • 节点维护(升级、 drain、 cordon)
   • 定期备份etcd数据
   • 版本升级规划和执行

# HPA示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

监控和日志

1. 监控：

   • 使用Prometheus收集指标
   • 配置Grafana仪表盘可视化
   • 设置Alertmanager告警规则

2. 日志：

   • 使用EFK(Elasticsearch, Fluentd, Kibana)或PLG(Promtail, Loki, Grafana)栈
   • 集中式日志收集和分析
   • 日志保留策略和合规性管理

扩容和缩容

1. 手动扩缩容：使用kubectl scale命令

2. 自动扩缩容：

   • HPA基于CPU/内存使用率
   • 自定义指标扩缩容
   • 基于事件的扩缩容(KEDA)

3. 集群扩缩容：

   • 节点自动扩缩容(Cluster Autoscaler)
   • 云提供商特定解决方案

故障排查

1. 常见问题排查：

   • Pod状态异常(CrashLoopBackOff, ImagePullBackOff等)
   • 服务不可用
   • 网络连接问题
   • 存储挂载问题

2. 排查工具：

   • kubectl describe/logs/exec
   • k9s、Lens等可视化工具
   • 事件监控

3. 排查流程：

   • 检查Pod状态和事件
   • 查看容器日志
   • 检查资源配置
   • 验证网络连通性
   • 检查依赖服务

实际项目案例和挑战

电商平台迁移项目

负责将传统电商平台迁移到K8s环境，主要挑战包括：

1. 有状态服务迁移：数据库和缓存服务迁移

   • 解决方案：使用StatefulSet和PVC，结合云服务商数据库服务

2. 会话保持问题：购物车和用户会话管理

   • 解决方案：引入Redis集群作为外部会话存储

3. 流量迁移：平滑过渡，零停机

   • 解决方案：使用Istio进行流量分割，逐步迁移

大数据处理平台

构建基于K8s的大数据处理平台，挑战包括：

1. 资源调度：大型作业资源需求波动大

   • 解决方案：使用KubeFlow和自定义调度器

2. 作业排队：资源竞争问题

   • 解决方案：实现Volcano作业调度系统

3. 数据处理加速：GPU和特殊硬件支持

   • 解决方案：配置设备插件和节点标签

最佳实践和经验教训

最佳实践

1. 基础设施即代码：所有配置通过Git管理，使用ArgoCD或Flux进行GitOps
2. 安全加固：
   • 使用RBAC进行权限控制
   • 网络策略限制Pod间通信
   • Pod安全标准(PSS)和Pod安全准入(PSA)
3. 多环境管理：使用命名空间分离环境，通过Kustomize管理环境差异
4. 成本优化：
   • 资源请求和限制合理设置
   • 使用混合节点池(按需和Spot实例)
   • 集群自动扩缩容

经验教训

1. 监控先行：先建立完善的监控，再部署关键应用
2. 渐进式迁移：避免一次性大规模迁移，采用渐进式策略
3. 文档记录：详细记录决策过程和配置细节
4. 持续学习：K8s生态发展迅速，保持持续学习

K8s带来的价值和未来方向

价值

1. 资源利用率提升：从传统虚拟机环境的30%提升到65%以上
2. 部署效率：部署时间从小时级缩短到分钟级
3. 自服务能力：开发团队可以自行部署和管理应用
4. 系统弹性：自动扩缩容应对流量波动

未来方向

1. 服务网格：深入Istio等服务网格技术
2. Serverless：探索Knative等Serverless框架
3. GitOps：全面推行GitOps工作流
4. 多云管理：使用Kubernetes Federation或类似工具管理多云环境

参考资源

• Kubernetes官方文档: https://kubernetes.io/docs/
• Kubernetes Patterns: https://kubernetespatterns.io/
• CNCF(Cloud Native Computing Foundation): https://www.cncf.io/
• K8s最佳实践: https://github.com/goldbergyoni/nodebestpractices#-6-kubernetes-and-docker