容器编排技术已成为现代应用部署的核心支撑，而Kubernetes（K8s）凭借其强大的自动化、高可用与扩展性，成为容器编排的事实标准。
本文从Kubernetes核心架构出发，详解从单节点集群搭建到生产级应用部署的全流程，重点聚焦Nginx基础部署与Redis集群的容器化实践，结合完整配置代码与架构图表，为开发者提供一套可直接落地的生产级部署方案。
一、Kubernetes核心架构：理解集群的”五脏六腑”
Kubernetes的本质是一个分布式容器编排平台，通过一系列核心组件实现对容器的生命周期管理、资源调度与服务发现。要掌握应用部署，首先需理解其底层架构与核心概念。
1.1 集群角色与核心组件
Kubernetes集群由两类节点组成：Master节点（控制平面）与Worker节点（工作节点），其组件分工如图1所示：
graph TD
subgraph Master节点（控制平面）
A[API Server] --> B[etcd]
A --> C[调度器（Scheduler）]
A --> D[控制器管理器（Controller Manager）]
end
subgraph Worker节点（工作节点）
E[kubelet] --> F[容器运行时（containerd）]
E --> G[Pod（容器组）]
H[kube-proxy] --> I[Service（服务发现）]
end
A <--> E[通信]
A <--> H[通信]
图1：Kubernetes集群核心组件架构图
| 节点类型 | 核心组件 | 功能说明 |
|---|---|---|
| Master节点 | API Server | 集群”网关”：接收所有操作请求（如部署应用、查询状态），提供RESTful API |
| etcd | 集群”数据库”：存储集群所有状态数据（如Pod配置、服务信息），强一致性存储 | |
| 调度器（Scheduler） | 资源”调度员”：根据节点资源（CPU/内存）与Pod需求，自动选择最佳Worker节点 | |
| 控制器管理器 | 状态”守护者”：确保集群实际状态与期望状态一致（如Pod故障时自动重启） | |
| Worker节点 | kubelet | 节点”管理员”：接收Master指令，管理本节点Pod的生命周期（创建/启动/停止） |
| 容器运行时（containerd） | 容器”引擎”：负责拉取镜像、创建容器，K8s v1.20+默认替代Docker | |
| kube-proxy | 网络”路由器”：维护节点网络规则，实现Service的负载均衡与Pod访问转发 |
1.2 核心概念：K8s部署的”基础词汇”
理解Kubernetes的核心概念是编写部署配置的前提，以下是应用部署中最常用的术语：
Pod：K8s的最小部署单元，由一个或多个紧密关联的容器组成（如Redis容器+监控容器），共享网络与存储。
特点：Pod是临时的，故障后会被重建，因此需通过上层控制器（如Deployment）管理。
Deployment：无状态应用的核心控制器，用于管理Pod的创建、扩缩容与滚动更新。
核心功能：维持指定数量的Pod副本（replicas），Pod故障时自动重建，支持灰度更新（如更新镜像时逐步替换旧Pod）。
StatefulSet：有状态应用的专用控制器（如Redis、数据库），与Deployment的关键区别在于：
为Pod提供稳定的网络标识（固定名称与DNS），如redis-0、redis-1；
支持有序部署/扩缩容（先启动主节点，再启动从节点）；
每个Pod绑定独立的持久化存储（PV/PVC），数据不随Pod重建丢失。
Service：Pod的网络访问抽象，解决PodIP动态变化的问题，提供稳定的访问端点。
核心类型：
ClusterIP：仅集群内访问（默认）；
NodePort：通过节点固定端口暴露服务（如30007），支持外部访问；
LoadBalancer：借助云厂商负载均衡器暴露服务（适合生产环境）；
Headless Service（无头服务）：clusterIP: None，直接返回PodIP，适合有状态应用的点对点通信（如Redis Cluster节点发现）。
PersistentVolume (PV) & PersistentVolumeClaim (PVC)：
PV：集群级别的持久化存储资源（如磁盘、云存储），由管理员预先创建；
PVC：Pod对存储资源的请求声明，类似”存储订单”，K8s自动匹配符合条件的PV。
作用：为有状态应用（如Redis）提供稳定存储，确保Pod重建后数据不丢失。
二、单节点Kubernetes集群极速搭建
在开始部署应用前，需先搭建Kubernetes集群。本节基于KubeKey工具实现单节点集群的一键安装，适合开发测试与小型生产环境。
2.1 环境准备与依赖安装
Kubernetes对宿主机环境有一定要求，需提前配置：
# 1. 关闭防火墙（生产环境可配置精细化规则）
sudo ufw disable # Ubuntu/Debian
# 或 CentOS：sudo systemctl stop firewalld && sudo systemctl disable firewalld
# 2. 禁用SELinux（避免权限拦截容器操作）
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
# 3. 关闭Swap（K8s要求禁用虚拟内存，避免影响性能）
sudo swapoff -a
sudo sed -i '/swap/s/^/#/' /etc/fstab # 永久禁用
# 4. 安装依赖工具
sudo apt update && sudo apt install -y socat conntrack ebtables ipset # Ubuntu/Debian
# 或 CentOS：sudo yum install -y socat conntrack-tools ebtables ipset
# 5. 配置内核参数（开启容器网络所需模块）
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system
2.2 基于KubeKey的一键安装
KubeKey是一款轻量的K8s安装工具，支持快速部署单节点或多节点集群，内置容器运行时（containerd），无需单独安装Docker：
# 1. 下载KubeKey（国内用户建议指定国内镜像源）
export KKZONE=cn # 使用国内镜像加速
curl -sfL https://get-kk.kubesphere.io | sh -
# 2. 赋予执行权限
chmod +x kk
# 3. 生成集群配置文件（默认版本v1.26.4，可按需修改）
./kk create config --with-kubernetes v1.26.4
# 4. 编辑配置文件（关键参数调整）
vi config-sample.yaml
# 需修改的核心配置：
# - hosts: 填写节点IP与SSH信息（单节点部署填写本机IP）
# - roleGroups: 确保master与worker节点均包含当前节点（单节点既是控制平面也是工作节点）
# - registry: 保留默认的国内镜像仓库（加速镜像拉取）
# 5. 一键部署集群（约10-15分钟，取决于网络速度）
./kk create cluster -f config-sample.yaml
# 6. 验证集群状态（出现"STATUS Ready"即为成功）
kubectl get nodes
# 输出示例：
# NAME STATUS ROLES AGE VERSION
# k8s-node1 Ready control-plane 10m v1.26.4
2.3 从Docker到Containerd的操作适配
Kubernetes v1.20+已弃用Docker作为容器运行时，改用containerd（更轻量、直接操作容器）。两者的镜像管理命令对比如表1所示：
| 操作场景 | Docker命令 | Containerd命令（crictl） | 说明 |
|---|---|---|---|
| 拉取镜像 | docker pull nginx:latest |
crictl pull docker.1ms.run/nginx:latest |
国内镜像源需替换为docker.1ms.run |
| 查看本地镜像 | docker images |
crictl images |
输出格式略有差异，但核心信息一致 |
| 查看运行中容器 | docker ps |
crictl ps |
支持-a查看所有容器（包括已停止） |
| 查看容器日志 | docker logs <容器ID> |
crictl logs <容器ID> |
支持-f实时跟踪日志 |
| 进入容器终端 | docker exec -it <容器ID> sh |
crictl exec -it <容器ID> sh |
交互方式完全一致 |
| 删除容器 | docker rm <容器ID> |
crictl rm <容器ID> |
需先停止容器（crictl stop <容器ID>） |
提示：若习惯Docker命令，可通过alias简化操作：alias docker=crictl（仅建议测试环境使用）。
三、基础应用部署：Nginx服务的容器化实践
Nginx作为经典的Web服务器，适合作为Kubernetes部署的入门案例。本节通过Deployment+Service实现Nginx的高可用部署，理解无状态应用的部署范式。
3.1 部署Nginx的核心资源配置
部署Nginx需定义两个核心资源：Deployment（管理Pod生命周期）与Service（暴露访问端点），完整配置如下：
（1）Deployment配置（nginx-deployment.yaml）
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment # Deployment名称
labels:
app: nginx # 标签（用于关联Service）
spec:
replicas: 2 # 副本数（2个Pod实现高可用）
selector:
matchLabels:
app: nginx # 匹配标签为app:nginx的Pod
strategy:
type: RollingUpdate # 滚动更新策略（默认）
rollingUpdate:
maxSurge: 1 # 更新时最多新增1个Pod
maxUnavailable: 0 # 更新时不可用Pod数为0（高可用保障）
template:
metadata:
labels:
app: nginx # Pod标签（需与selector匹配）
spec:
containers:
- name: nginx # 容器名称
image: docker.1ms.run/nginx:latest # 镜像（国内源）
ports:
- containerPort: 80 # 容器内端口（Nginx默认端口）
resources: # 资源限制（避免资源抢占）
requests: # 最小资源需求
cpu: "100m" # 100毫核（0.1核）
memory: "128Mi"
limits: # 最大资源限制
cpu: "500m"
memory: "256Mi"
livenessProbe: # 存活探针（检测容器健康状态）
httpGet:
path: /
port: 80
initialDelaySeconds: 30 # 启动后30秒开始检测
periodSeconds: 10 # 每10秒检测一次
readinessProbe: # 就绪探针（检测容器是否可提供服务）
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
关键配置说明：
replicas: 2：部署2个Pod副本，实现负载均衡与故障自愈（一个Pod故障时，另一个仍可提供服务）；
资源限制（requests/limits）：防止Nginx占用过多资源，避免影响其他应用；
探针（livenessProbe/readinessProbe）：K8s通过HTTP请求检测Nginx状态，不健康时自动重启容器。
（2）Service配置（nginx-service.yaml）
apiVersion: v1
kind: Service
metadata:
name: nginx-service # Service名称
spec:
selector:
app: nginx # 关联标签为app:nginx的Pod
type: NodePort # 暴露服务类型（节点端口）
ports:
- port: 80 # Service端口（集群内访问端口）
targetPort: 80 # 目标Pod端口（需与容器端口一致）
nodePort: 30007 # 节点暴露端口（范围30000-32767，需唯一）
Service作用：
为动态变化的Pod提供稳定访问端点（如10.96.xx.xx:80）；
通过NodePort: 30007暴露服务到集群外部，可通过节点IP:30007访问Nginx。
3.2 部署与验证流程
通过kubectl命令部署应用并验证状态：
# 1. 部署Deployment与Service
kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-service.yaml
# 2. 查看Deployment状态（确保READY为2/2）
kubectl get deployment nginx-deployment
# 输出示例：
# NAME READY UP-TO-DATE AVAILABLE AGE
# nginx-deployment 2/2 2 2 5m
# 3. 查看Pod状态（确保STATUS为Running）
kubectl get pods -l app=nginx # 通过标签筛选Pod
# 输出示例：
# NAME READY STATUS RESTARTS AGE
# nginx-deployment-7f897d65c4-2xq9k 1/1 Running 0 5m
# nginx-deployment-7f897d65c4-zm7k8 1/1 Running 0 5m
# 4. 查看Service状态（获取NodePort）
kubectl get service nginx-service
# 输出示例：
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# nginx-service NodePort 10.96.123.45 <none> 80:30007/TCP 5m
# 5. 访问Nginx服务（替换为实际节点IP）
curl http://<节点公网IP>:30007
# 输出Nginx默认首页HTML即为成功
# 6. 验证高可用（删除一个Pod，观察是否自动重建）
kubectl delete pod <Pod名称> # 如nginx-deployment-7f897d65c4-2xq9k
kubectl get pods -l app=nginx # 约10秒后会出现新Pod（RESTARTS=0）
高可用验证结果：删除一个Pod后，Deployment会自动创建新Pod维持replicas=2，期间另一个Pod正常提供服务，实现业务无感知故障转移。
四、有状态应用部署：Redis集群的容器化方案
Redis作为典型的有状态应用（需持久化数据、节点间有依赖关系），其Kubernetes部署比Nginx更复杂。本节详解Redis的三种部署模式（单实例、主从复制、Cluster集群），重点聚焦生产级集群方案。
4.1 Redis部署的核心挑战与解决方案
有状态应用在K8s中部署需解决三大问题，其解决方案如表2所示：
| 核心挑战 | 解决方案 | 关键K8s资源 |
|---|---|---|
| 数据持久化（避免丢失） | 绑定持久化存储，Pod重建后数据可恢复 | PersistentVolume (PV)、PersistentVolumeClaim (PVC) |
| 稳定网络标识（节点发现） | 固定Pod名称与DNS解析，支持节点间通信 | StatefulSet、Headless Service |
| 有序部署/扩缩容（主从依赖） | 按顺序启动/停止Pod，确保主节点先于从节点部署 | StatefulSet（orderedReady: true） |
4.2 模式一：单实例Redis（开发测试用）
单实例Redis适合开发测试场景，架构简单（1个Pod+1个PVC），但无高可用能力（生产环境禁用）。
（1）创建PVC（持久化存储）
# redis-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: redis-data-pvc
spec:
storageClassName: standard # 存储类（需集群已配置，单节点默认可用）
accessModes:
- ReadWriteOnce # 单节点读写（Redis单实例独占存储）
resources:
requests:
storage: 10Gi # 申请10GB存储
（2）部署单实例Redis
# redis-standalone.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-standalone
spec:
replicas: 1 # 仅1个副本（无高可用）
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:7.0.12-alpine # 轻量Redis镜像
command: ["redis-server", "/etc/redis/redis.conf"] # 指定配置文件
ports:
- containerPort: 6379 # Redis默认端口
volumeMounts:
- name: redis-data # 挂载数据目录（持久化）
mountPath: /data
- name: redis-config # 挂载配置文件
mountPath: /etc/redis/
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
volumes:
- name: redis-data
persistentVolumeClaim:
claimName: redis-data-pvc # 绑定PVC
- name: redis-config
configMap:
name: redis-config # 绑定ConfigMap（见下方配置）
---
# 配置文件（ConfigMap）
apiVersion: v1
kind: ConfigMap
metadata:
name: redis-config
data:
redis.conf: |
appendonly yes # 开启AOF持久化
port 6379
bind 0.0.0.0 # 允许所有IP访问（仅测试环境）
（3）部署与验证
# 1. 创建ConfigMap和PVC
kubectl apply -f redis-standalone.yaml # 包含ConfigMap
kubectl apply -f redis-pvc.yaml
# 2. 查看Pod状态
kubectl get pods -l app=redis
# 3. 进入Pod验证数据持久化
kubectl exec -it <Pod名称> -- redis-cli
127.0.0.1:6379> SET testkey "persistent" # 写入测试数据
OK
127.0.0.1:6379> GET testkey
"persistent"
# 4. 删除Pod（模拟故障）
kubectl delete pod <Pod名称>
# 5. 新Pod启动后验证数据
kubectl exec -it <新Pod名称> -- redis-cli
127.0.0.1:6379> GET testkey # 数据仍存在（PVC生效）
"persistent"
4.3 模式二：Redis主从复制（Sentinel高可用）
主从复制架构由1主N从+M哨兵（Sentinel）组成，哨兵监控主节点状态，故障时自动切换主从角色，适合读多写少场景。
（1）核心资源与架构
graph TD
Client[客户端] --> S[哨兵集群]
S --> M[主Redis Pod]
M --> S1[从Redis Pod 1]
M --> S2[从Redis Pod 2]
S -->|故障切换| S1 # 主节点故障时，哨兵将从节点晋升为主
S -->|故障切换| S2
M --> PV1[PVC 1] # 主节点数据持久化
S1 --> PV2[PVC 2] # 从节点数据持久化
S2 --> PV3[PVC 3]
图2：Redis主从复制（Sentinel）架构图
核心资源包括：
StatefulSet：部署3个Redis节点（1主2从），每个节点绑定独立PVC；
ConfigMap：存储redis.conf（主从配置）与sentinel.conf（哨兵配置）；
Headless Service：为Redis节点提供固定DNS（如redis-0.redis-headless）；
哨兵容器：可作为Sidecar（与Redis同Pod）或独立Pod部署。
（2）关键配置示例（StatefulSet）
# redis-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis
spec:
serviceName: "redis-headless" # 关联Headless Service
replicas: 3 # 3个节点（1主2从）
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:7.0.12-alpine
command: ["/bin/sh", "-c"]
args:
- |
# 根据Pod序号初始化角色（0为主节点，1/2为从节点）
if [ $HOSTNAME = "redis-0" ]; then
redis-server /etc/redis/redis.conf --slaveof no
else
redis-server /etc/redis/redis.conf --slaveof redis-0.redis-headless 6379
fi
ports:
- containerPort: 6379
volumeMounts:
- name: data
mountPath: /data
- name: config
mountPath: /etc/redis/
- name: sentinel # 哨兵Sidecar容器
image: redis:7.0.12-alpine
command: ["redis-sentinel", "/etc/sentinel/sentinel.conf"]
volumeMounts:
- name: sentinel-config
mountPath: /etc/sentinel/
volumeClaimTemplates: # 动态生成PVC（每个Pod一个）
- metadata:
name: data
spec:
storageClassName: standard
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
---
# Headless Service（用于节点发现）
apiVersion: v1
kind: Service
metadata:
name: redis-headless
spec:
clusterIP: None # 无头服务标志
selector:
app: redis
ports:
- port: 6379
targetPort: 6379
（3）哨兵配置（ConfigMap）
# redis-sentinel-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: redis-config
data:
redis.conf: |
appendonly yes
port 6379
bind 0.0.0.0
---
apiVersion: v1
kind: ConfigMap
metadata:
name: sentinel-config
data:
sentinel.conf: |
port 26379
sentinel monitor mymaster redis-0.redis-headless 6379 2 # 监控主节点，2个哨兵同意则判定故障
sentinel down-after-milliseconds mymaster 5000 # 5秒无响应视为故障
sentinel failover-timeout mymaster 10000 # 故障切换超时时间
（4）验证主从关系
# 1. 部署资源
kubectl apply -f redis-statefulset.yaml
kubectl apply -f redis-sentinel-config.yaml
# 2. 查看StatefulSet状态
kubectl get statefulset redis
# 输出示例：
# NAME READY AGE
# redis 3/3 10m
# 3. 验证主从关系（进入redis-1 Pod）
kubectl exec -it redis-1 -- redis-cli
127.0.0.1:6379> INFO replication
# 输出应包含"role:slave"和"master_host:redis-0.redis-headless"
# 4. 模拟主节点故障（删除redis-0 Pod）
kubectl delete pod redis-0
# 5. 验证故障切换（约30秒后）
kubectl exec -it redis-1 -- redis-cli INFO replication
# 此时redis-1或redis-2应晋升为"role:master"
4.4 模式三：Redis Cluster（生产级分布式方案）
Redis Cluster是官方分布式方案，通过分片（Shard）存储数据（16384个哈希槽），支持3主3从架构（自动故障转移），适合大规模生产环境。
（1）核心架构与资源
graph TD
Client[客户端] --> CS[Cluster Service]
CS --> M1[主节点1（槽0-5460）]
CS --> M2[主节点2（槽5461-10922）]
CS --> M3[主节点3（槽10923-16383）]
M1 --> S1[从节点1（备份M1）]
M2 --> S2[从节点2（备份M2）]
M3 --> S3[从节点3（备份M3）]
M1 <--> M2 <--> M3 # 节点间通信（Gossip协议）
图3：Redis Cluster（3主3从）架构图
核心资源：
StatefulSet：部署6个节点（3主3从），每个节点绑定独立PVC；
Headless Service：支持节点间点对点通信（哈希槽迁移、故障检测）；
Init Container：初始化集群（分配哈希槽、建立主从关系）。
（2）关键配置示例
# redis-cluster.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis-cluster
spec:
serviceName: "redis-cluster-headless"
replicas: 6 # 6节点：3主3从
podManagementPolicy: Parallel # 并行启动（加速初始化）
selector:
matchLabels:
app: redis-cluster
template:
metadata:
labels:
app: redis-cluster
spec:
initContainers: # 初始化容器（集群创建前执行）
- name: init-redis
image: redis:7.0.12-alpine
command:
- sh
- -c
- |
# 生成节点配置文件
echo "cluster-enabled yes" > /etc/redis/redis.conf
echo "cluster-config-file nodes.conf" >> /etc/redis/redis.conf
echo "cluster-node-timeout 5000" >> /etc/redis/redis.conf
echo "appendonly yes" >> /etc/redis/redis.conf
echo "bind 0.0.0.0" >> /etc/redis/redis.conf
volumeMounts:
- name: config
mountPath: /etc/redis/
containers:
- name: redis
image: redis:7.0.12-alpine
command: ["redis-server", "/etc/redis/redis.conf"]
ports:
- containerPort: 6379 # 客户端端口
- containerPort: 16379 # 集群总线端口（节点间通信）
volumeMounts:
- name: data
mountPath: /data
- name: config
mountPath: /etc/redis/
env:
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP # 注入Pod IP（用于集群初始化）
volumes:
- name: config
emptyDir: {
} # 临时存储配置文件
volumeClaimTemplates: # 每个节点独立PVC
- metadata:
name: data
spec:
storageClassName: standard
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
---
# Headless Service（集群节点发现）
apiVersion: v1
kind: Service
metadata:
name: redis-cluster-headless
spec:
clusterIP: None
selector:
app: redis-cluster
ports:
- port: 6379
targetPort: 6379
- port: 16379
targetPort: 16379
（3）集群初始化（关键步骤）
Redis Cluster需手动或自动执行初始化命令（分配哈希槽、建立主从关系）：
# 1. 部署StatefulSet
kubectl apply -f redis-cluster.yaml
# 2. 等待所有Pod运行（6/6 Ready）
kubectl get pods -l app=redis-cluster
# 3. 进入任意Pod（如redis-cluster-0）
kubectl exec -it redis-cluster-0 -- sh
# 4. 初始化集群（分配哈希槽，3主3从）
redis-cli --cluster create
redis-cluster-0.redis-cluster-headless:6379
redis-cluster-1.redis-cluster-headless:6379
redis-cluster-2.redis-cluster-headless:6379
redis-cluster-3.redis-cluster-headless:6379
redis-cluster-4.redis-cluster-headless:6379
redis-cluster-5.redis-cluster-headless:6379
--cluster-replicas 1 # 每个主节点1个从节点
# 5. 验证集群状态
redis-cli cluster info
# 输出应包含"cluster_state:ok"
# 6. 查看哈希槽分配
redis-cli cluster slots
# 3个主节点应分别分配0-5460、5461-10922、10923-16383槽
（4）生产级优化配置
密码认证：通过Secret存储密码，配置requirepass与masterauth；
资源限制：根据实际负载调整CPU/内存（建议Redis内存限制≥2GB）；
监控告警：集成Prometheus+Grafana，监控cluster_health、used_memory等指标；
备份策略：定期对PVC创建快照（如使用Velero工具），防止数据丢失。
五、生产级部署最佳实践与总结
无论是部署Nginx等无状态应用，还是Redis等有状态应用，生产级Kubernetes部署需遵循一套通用原则，确保高可用、安全性与可维护性。
5.1 通用最佳实践
资源管理：
为所有容器设置requests（确保资源预留）与limits（防止资源滥用），避免因资源竞争导致应用不稳定。
健康检查：
配置livenessProbe（检测容器存活）与readinessProbe（检测服务就绪），K8s会自动重启不健康的容器。
配置与密钥管理：
非敏感配置（如Nginx.conf、Redis.conf）存入ConfigMap，支持动态更新；
敏感信息（如密码、API密钥）存入Secret，避免明文暴露。
持久化存储：
有状态应用必须使用PV/PVC，生产环境优先选择高性能存储（如本地SSD、云厂商高性能云盘），确保低延迟。
网络安全：
非必要不使用NodePort，生产环境优先用LoadBalancer或Ingress；
通过NetworkPolicy限制Pod间通信（如仅允许Redis从节点访问主节点）。
监控与日志：
集成监控工具（如Prometheus），跟踪Pod状态、资源使用率与应用指标；
配置集中式日志（如EFK栈），便于问题排查。
5.2 从基础到进阶的部署路线图
Kubernetes部署能力的提升需循序渐进，建议按以下路线图实践：
入门级：掌握单节点集群搭建，部署Nginx等无状态应用，理解Deployment与Service；
进阶级：部署Redis单实例与主从复制，掌握StatefulSet、PV/PVC与Headless Service；
专家级：实现Redis Cluster生产级部署，集成监控、备份与自动扩缩容，解决网络延迟、数据一致性等复杂问题。
5.3 总结
Kubernetes为应用部署提供了强大的自动化与扩展性，但也带来了一定的学习门槛。本文从架构解析到实战部署，详细讲解了Nginx与Redis在K8s中的部署方案，核心要点包括：
无状态应用用Deployment+Service，追求简单与高可用；
有状态应用用StatefulSet+Headless Service+PV/PVC，解决数据持久化与节点发现；
生产环境需已关注资源管理、安全配置与监控告警，确保应用稳定运行。
随着云原生技术的发展，Kubernetes已成为企业级应用部署的标配。掌握本文所述的部署方法与最佳实践，开发者可轻松应对从简单Web服务到复杂分布式集群的容器化需求，为业务系统的高可用与可扩展奠定坚实基础。
暂无评论内容