一个过渡昵称1. 为什么需要Kubernetes？
在容器技术普及之前，我们部署应用通常采用物理机或虚拟机方式。这种方式存在几个明显痛点：
- 资源利用率低：每个应用独占一台服务器，CPU和内存经常闲置
- 部署效率低下：从申请机器到应用上线需要数天时间
- 扩缩容困难：遇到流量高峰时手动扩容速度慢
- 环境不一致：开发、测试、生产环境差异导致各种"在我机器上是好的"问题
Docker的出现解决了环境一致性问题，但单机Docker仍然面临资源调度、服务发现、自动扩缩容等挑战。这就是Kubernetes（简称k8s）诞生的背景。
提示：k8s名称中的"8"代表"ubernete"这8个字母，是技术圈常见的数字缩写方式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Kubernetes核心架构解析
2.1 控制平面组件
控制平面是k8s的大脑，包含以下关键组件：
- API Server：集群的唯一切入点，提供RESTful API
- etcd：分布式键值存储，保存集群所有配置数据
- Scheduler：负责将Pod调度到合适的Node上
- Controller Manager：运行各种控制器，确保集群处于预期状态
2.2 工作节点组件
每个工作节点（Node）运行以下核心组件：
- kubelet：节点代理，负责与API Server通信
- kube-proxy：维护节点网络规则，实现服务发现和负载均衡
- 容器运行时：如Docker、containerd等，实际运行容器
2.3 核心概念模型
理解这些抽象概念是掌握k8s的关键：
- Pod：最小部署单元，包含一个或多个紧密关联的容器
- Deployment：声明式管理Pod副本集，支持滚动更新
- Service：定义一组Pod的访问策略，实现服务发现
- Namespace：虚拟集群，用于资源隔离
3. 典型部署架构设计
3.1 开发测试环境部署
对于小型团队，推荐以下配置：
bash复制# 使用kubeadm快速搭建集群
kubeadm init --pod-network-cidr=10.244.0.0/16
kubeadm join <master-ip>:<port> --token <token>
3.2 生产环境高可用架构
生产环境建议采用多Master节点确保控制平面高可用：
- 负载均衡层：使用Nginx或云厂商LB服务
- 多Master节点：至少3个节点组成etcd集群
- 工作节点池：根据业务需求划分不同规格的节点组
- 网络插件：Calico或Flannel实现Pod网络互通
4. 常见问题排查思路
4.1 Pod启动失败排查流程
- 检查Pod描述信息：
bash复制
kubectl describe pod <pod-name> - 查看容器日志：
bash复制
kubectl logs <pod-name> [-c <container-name>] - 验证基础配置：
- 资源配额是否足够
- 镜像地址是否正确
- 存储卷是否正常挂载
4.2 网络连接问题
典型错误："你的连接不是专用连接"通常与以下因素有关：
-
证书配置问题：
- 检查kubeconfig文件中的证书是否过期
- 验证API Server证书包含所有访问域名
-
网络策略限制：
- 检查NetworkPolicy是否阻止了必要流量
- 验证Service的selector是否匹配Pod标签
-
Ingress配置：
- 检查Ingress Controller是否正常运行
- 验证域名解析是否正确
5. 性能优化实践
5.1 资源配额管理
通过ResourceQuota限制命名空间资源使用：
yaml复制apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-cpu-demo
spec:
hard:
requests.cpu: "2"
requests.memory: 4Gi
limits.cpu: "4"
limits.memory: 8Gi
5.2 节点资源监控
使用Metrics Server收集资源指标：
bash复制# 部署Metrics Server
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 查看节点资源使用
kubectl top nodes
6. 安全最佳实践
6.1 RBAC权限控制
为不同角色创建最小权限：
yaml复制apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
6.2 敏感信息管理
使用Secret存储敏感数据：
bash复制# 从文件创建Secret
kubectl create secret generic db-secret \
--from-file=username=./username.txt \
--from-file=password=./password.txt
7. 监控方案实施
7.1 Prometheus外部监控方案
当Prometheus部署在k8s集群外时：
-
配置ServiceMonitor：
yaml复制apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app spec: endpoints: - port: web selector: matchLabels: app: example-app -
设置访问权限：
- 创建具有只读权限的ServiceAccount
- 配置kubeconfig供Prometheus使用
-
网络连通性：
- 确保Prometheus能访问k8s API
- 配置必要的网络策略和防火墙规则
8. 持续集成部署
8.1 GitOps工作流实现
使用Argo CD实现声明式部署：
-
安装Argo CD：
bash复制
kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml -
配置应用同步：
yaml复制apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook spec: destination: server: https://kubernetes.default.svc source: path: guestbook repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD
9. 存储方案选型
9.1 本地存储vs网络存储
| 特性 | 本地存储 | 网络存储 |
|---|---|---|
| 性能 | 高 | 中 |
| 可靠性 | 低（节点故障数据丢失） | 高 |
| 适用场景 | 临时数据、缓存 | 持久化数据 |
| 典型实现 | hostPath, emptyDir | NFS, Ceph, 云盘 |
9.2 StatefulSet有状态应用部署
部署PostgreSQL示例：
yaml复制apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
serviceName: "postgres"
replicas: 3
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:13
volumeMounts:
- name: pgdata
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: pgdata
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
10. 服务网格集成
10.1 Istio核心功能
-
流量管理：
- 金丝雀发布
- A/B测试
- 故障注入
-
可观测性：
- 分布式追踪
- 指标收集
- 日志聚合
-
安全机制：
- mTLS加密
- 细粒度访问控制
10.2 安装配置要点
bash复制# 下载istioctl
curl -L https://istio.io/downloadIstio | sh -
# 安装demo配置
istioctl install --set profile=demo -y
# 启用自动sidecar注入
kubectl label namespace default istio-injection=enabled
在k8s集群中运行工作负载时，资源定义文件通常需要包含以下关键部分：
yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
对于配置管理，ConfigMap是常用方案。当遇到"configmap执行脚本 permission denied"错误时，通常需要：
-
检查脚本文件权限：
bash复制kubectl exec -it <pod-name> -- ls -l /path/to/script.sh -
确保容器用户有执行权限：
yaml复制securityContext: runAsUser: 1000 fsGroup: 2000 -
考虑使用initContainer预先设置权限：
yaml复制initContainers: - name: set-permissions image: busybox command: ["chmod", "+x", "/path/to/script.sh"] volumeMounts: - name: config-volume mountPath: /path/to/script.sh
当节点CPU占用率过高时，排查步骤应包括：
-
识别问题节点：
bash复制
kubectl top nodes -
检查节点详细指标：
bash复制
kubectl describe node <node-name> -
分析具体Pod资源使用：
bash复制
kubectl top pods -A --sort-by=cpu -
检查可能的原因：
- 配置了不合理的resource limits
- 存在资源泄漏的应用程序
- 节点规格与工作负载不匹配
对于Java应用（如Ruoyi-Cloud）的k8s部署，特别注意：
-
JVM内存参数需要与容器limits匹配：
yaml复制env: - name: JAVA_OPTS value: "-Xmx1g -Xms1g" -
使用就绪探针确保完全启动：
yaml复制readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 -
考虑添加Sidecar容器处理日志收集等辅助功能