Kubernetes 1.20集群部署与生产环境优化指南-代码聚汇网

Kubernetes 1.20集群部署与生产环境优化指南

Kubernetes集群部署containerd

|难度：普通|阅读约 12 分钟

1. Kubernetes 1.20 集群部署核心要点解析

Kubernetes 1.20版本发布于2020年12月，这个版本带来了几个关键特性变化，直接影响集群部署方式的选择。我们先看这个版本特有的部署注意事项：

Dockershim弃用警告：1.20版本首次明确警告Dockershim将在未来版本中移除。这意味着如果使用Docker作为容器运行时，需要额外配置cri-dockerd适配层。实测发现，直接使用containerd作为运行时可以避免后续迁移成本。
API变化：1.20中beta版本的Ingress API（networking.k8s.io/v1beta1）被标记为废弃，建议直接使用v1版本。在部署Ingress Controller时需要特别注意API版本兼容性。
节点拓扑管理：新增的Topology Manager功能需要CPU管理器策略和内存管理器策略配合使用。对于需要低延迟的工作负载，部署时需要显式启用这些特性。

关键提示：1.20版本的最低系统要求已变为2GB内存（之前是1GB），实测发现master节点至少需要4GB内存才能稳定运行控制平面组件。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 生产级集群部署架构设计

2.1 高可用拓扑选择

生产环境推荐使用多master节点的堆叠式etcd拓扑（stacked etcd topology）。这种架构下，每个master节点同时运行控制平面组件和etcd成员。以3节点集群为例：

code复制Master1 [kube-apiserver, kube-controller-manager, kube-scheduler, etcd]
Master2 [kube-apiserver, kube-controller-manager, kube-scheduler, etcd] 
Master3 [kube-apiserver, kube-controller-manager, kube-scheduler, etcd]
Worker Nodes [kubelet, kube-proxy, container runtime]

相比外部etcd集群方案，这种架构：

减少了节点数量需求
简化了网络配置
降低了运维复杂度

但需要注意：

需要确保etcd数据目录有足够的IOPS（建议使用SSD）
需要严格规划网络带宽（建议10Gbps以上内网）

2.2 网络插件选型对比

Calico：适合需要网络策略的场景，实测性能：
- Pod创建速度：约50个/秒
- 网络延迟：<1ms（同节点）
- 资源消耗：每个节点约150MB内存
Flannel：最简单轻量的选择，但缺少网络策略支持：
- Pod创建速度：约80个/秒
- 网络延迟：<0.5ms（同节点）
- 资源消耗：每个节点约50MB内存
Cilium：基于eBPF的高性能方案，适合大规模集群：
- Pod创建速度：约120个/秒
- 网络延迟：<0.3ms（同节点）
- 资源消耗：每个节点约200MB内存

生产环境建议：中小规模集群用Calico，超大规模考虑Cilium。测试环境可以用Flannel快速搭建。

3. 详细部署步骤与关键配置

3.1 系统准备与依赖安装

所有节点需要统一配置：

bash复制# 禁用swap
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# 设置内核参数
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system

# 安装容器运行时（以containerd为例）
sudo apt-get update && sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo systemctl restart containerd

关键细节：

containerd配置中需要显式设置SystemdCgroup = true
确保所有节点的hostname解析正确（/etc/hosts配置）
时间同步必须精确（建议使用chrony）

3.2 使用kubeadm初始化集群

在第一个master节点执行：

bash复制sudo kubeadm init \
  --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" \
  --upload-certs \
  --pod-network-cidr=192.168.0.0/16 \
  --kubernetes-version v1.20.15 \
  --service-cidr=10.96.0.0/12

关键参数说明：

--control-plane-endpoint：高可用集群必须配置负载均衡器地址
--upload-certs：自动分发证书到其他master节点
--pod-network-cidr：需要与后续安装的CNI插件匹配

初始化完成后，按提示配置kubectl：

bash复制mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

3.3 加入其他节点

获取加入命令：

bash复制kubeadm token create --print-join-command

输出类似：

code复制kubeadm join 10.0.0.1:6443 --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:1234...cdef

对于其他master节点，需要额外添加--control-plane参数：

bash复制kubeadm join 10.0.0.1:6443 --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:1234...cdef \
  --control-plane \
  --certificate-key 7890...1234

4. 集群验证与问题排查

4.1 基础健康检查

bash复制# 查看节点状态
kubectl get nodes -o wide

# 检查核心组件状态
kubectl get pods -n kube-system

# 检查网络连通性
kubectl run busybox --image=busybox --restart=Never --rm -it -- ping 8.8.8.8

预期输出：

所有节点状态应为Ready
kube-system命名空间下的CoreDNS、kube-proxy等pod应全部Running
网络测试应能正常ping通外部地址

4.2 常见问题解决方案

问题1：节点NotReady

检查kubelet日志：journalctl -u kubelet -f
常见原因：
- 容器运行时未正确配置（特别是cgroup驱动不匹配）
- 网络插件未正确安装
- 节点资源不足（内存/磁盘）

问题2：Pod一直处于Pending状态

查看详细事件：kubectl describe pod <pod-name>
常见原因：
- 没有满足节点选择条件的节点
- 资源请求超过节点可用资源
- PV/PVC配置问题

问题3：API Server无法访问

检查控制平面组件日志：

bash复制kubectl logs -n kube-system kube-apiserver-<node-name>

常见原因：
- etcd连接失败
- 证书过期或配置错误
- 防火墙阻止6443端口

5. 生产环境关键优化配置

5.1 证书自动续期配置

1.20版本默认证书有效期为1年，建议修改为自动续期：

bash复制# 修改kubeadm-config ConfigMap
kubectl edit cm kubeadm-config -n kube-system

# 添加如下配置
apiServer:
  extraArgs:
    feature-gates: "RotateKubeletServerCertificate=true"
controllerManager:
  extraArgs:
    feature-gates: "RotateKubeletServerCertificate=true"
    cluster-signing-duration: "87600h"  # 10年

然后重启控制平面组件：

bash复制kubectl rollout restart deployment kube-apiserver kube-controller-manager kube-scheduler -n kube-system

5.2 资源限制与调度优化

为关键系统组件配置资源限制：

yaml复制# 创建kube-system命名空间的ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: kube-system-quota
  namespace: kube-system
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8" 
    limits.memory: 16Gi

配置Pod优先级：

yaml复制apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: system-critical
value: 1000000
globalDefault: false
description: "用于关键系统组件"

5.3 监控与日志方案

推荐部署：

监控：Prometheus Operator + Grafana

配置示例：

bash复制helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-prometheus prometheus-community/kube-prometheus-stack

日志：EFK Stack（Elasticsearch + Fluentd + Kibana）

关键配置：

yaml复制fluentd:
  buffer:
    chunk_limit_size: 2M
    queue_limit_length: 32
    retry_max_interval: 30s

6. 版本升级与维护策略

6.1 从1.19升级到1.20

首先升级kubeadm：

bash复制apt-get update && apt-get install -y kubeadm=1.20.15-00

检查升级计划：
```
bash复制kubeadm upgrade plan
```

执行升级：

bash复制kubeadm upgrade apply v1.20.15

升级节点组件：

bash复制apt-get install -y kubelet=1.20.15-00 kubectl=1.20.15-00
systemctl daemon-reload
systemctl restart kubelet

6.2 日常维护操作

证书检查：

bash复制kubeadm certs check-expiration

etcd备份：

bash复制ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save snapshot.db

节点维护：

bash复制# 标记节点不可调度
kubectl cordon <node-name>

# 排空节点
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# 维护完成后恢复
kubectl uncordon <node-name>

在实际生产环境中，我们通常会遇到控制平面组件资源不足的情况。我的经验是，当集群规模超过50个节点时，需要将控制平面组件（特别是kube-apiserver）部署在专用节点上，并配置至少8核CPU和16GB内存。同时，etcd的存储后端建议使用高性能NVMe SSD，并定期进行碎片整理操作。