Kubernetes集群的搭建与DevOps实践（上）- 架构设计篇
<blockquote><p>本文将探讨生产级Kubernetes集群的架构设计、技术选型，以及完整的DevOps体系设计</p>
<p><strong>适合读者</strong>：架构师、技术负责人、希望深入理解K8s和DevOps设计原理的工程师</p>
</blockquote>
<hr>
<h2 id="目录">目录</h2>
<ul>
<li>一、为什么需要Kubernetes</li>
<li>二、整体架构设计</li>
<li>三、技术选型与对比</li>
<li>四、DevOps体系设计</li>
<li>五、中间件体系设计</li>
<li>六、K8s核心概念精要</li>
<li>七、设计决策分析</li>
<li>八、总结与最佳实践</li>
</ul>
<hr>
<h2 id="一为什么需要kubernetes">一、为什么需要Kubernetes</h2>
<h3 id="11-传统部署的痛点">1.1 传统部署的痛点</h3>
<p>在引入容器编排之前，典型的应用部署方式存在以下问题：</p>
<table>
<thead>
<tr>
<th>问题类型</th>
<th>具体表现</th>
<th>业务影响</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>部署效率低</strong></td>
<td>手工SSH登录、停止服务、上传文件、启动服务</td>
<td>每次部署30分钟+，容易出错</td>
</tr>
<tr>
<td><strong>单点故障</strong></td>
<td>服务器宕机导致业务完全中断</td>
<td>服务可用性低于95%</td>
</tr>
<tr>
<td><strong>扩容困难</strong></td>
<td>增加服务器需要手工配置环境、部署应用</td>
<td>扩容耗时2小时+，错过业务高峰</td>
</tr>
<tr>
<td><strong>资源利用率低</strong></td>
<td>按峰值配置资源，平时大量闲置</td>
<td>CPU平均使用率仅15-25%</td>
</tr>
<tr>
<td><strong>配置管理混乱</strong></td>
<td>配置文件散落在各服务器，无版本管理</td>
<td>环境不一致导致故障</td>
</tr>
<tr>
<td><strong>无法回滚</strong></td>
<td>出问题只能再走一遍部署流程</td>
<td>故障恢复时间15-20分钟</td>
</tr>
</tbody>
</table>
<h3 id="12-kubernetes能解决什么问题">1.2 Kubernetes能解决什么问题</h3>
<table>
<thead>
<tr>
<th>痛点</th>
<th>K8s解决方案</th>
<th>实际效果</th>
</tr>
</thead>
<tbody>
<tr>
<td>部署效率低</td>
<td>声明式Deployment + 滚动更新</td>
<td>部署时间：30分钟 -> 5分钟</td>
</tr>
<tr>
<td>单点故障</td>
<td>Pod副本 + 健康检查 + 自动重启</td>
<td>可用性：95% -> 99.5%</td>
</tr>
<tr>
<td>扩容困难</td>
<td>水平扩缩容(HPA)</td>
<td>扩容时间：2小时 -> 2分钟</td>
</tr>
<tr>
<td>资源利用率低</td>
<td>智能调度 + 资源配额</td>
<td>CPU利用率：25% -> 60%</td>
</tr>
<tr>
<td>配置管理混乱</td>
<td>ConfigMap + Secret</td>
<td>集中管理，版本可追溯</td>
</tr>
<tr>
<td>无法回滚</td>
<td>滚动更新 + 版本历史</td>
<td>一键回滚，30秒完成</td>
</tr>
</tbody>
</table>
<h3 id="13-技术方案对比">1.3 技术方案对比</h3>
<table>
<thead>
<tr>
<th>方案</th>
<th>优势</th>
<th>劣势</th>
<th>适用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Docker Compose</strong></td>
<td>简单易用、学习成本低</td>
<td>不支持集群、无法水平扩展</td>
<td>开发环境、单机小应用</td>
</tr>
<tr>
<td><strong>Docker Swarm</strong></td>
<td>轻量级、易上手、与Docker无缝集成</td>
<td>生态不如K8s、功能有限</td>
<td>中小型项目、快速原型</td>
</tr>
<tr>
<td><strong>Kubernetes</strong></td>
<td>功能强大、生态丰富、行业标准</td>
<td>学习曲线陡峭、运维复杂</td>
<td>中大型生产环境</td>
</tr>
<tr>
<td><strong>云原生PaaS</strong></td>
<td>开箱即用、免运维</td>
<td>成本高、厂商绑定</td>
<td>预算充足的企业</td>
</tr>
</tbody>
</table>
<p><strong>选择Kubernetes的核心理由</strong>：</p>
<ol>
<li><strong>声明式API</strong>：告诉系统"我要什么"而非"怎么做"，系统自动达成目标状态</li>
<li><strong>自愈能力</strong>：Pod崩溃自动重启，节点故障自动迁移</li>
<li><strong>生态成熟</strong>：几乎任何需求都有现成解决方案</li>
<li><strong>行业标准</strong>：人才储备充足，问题容易解决</li>
</ol>
<hr>
<h2 id="二整体架构设计">二、整体架构设计</h2>
<h3 id="21-架构拓扑图">2.1 架构拓扑图</h3>
<div class="mermaid">graph TB
subgraph 外网访问层
Internet[互联网用户]
Internet --> Entry
end
subgraph 内网管理层
JumpServer[堡垒机<br/>JumpServer]
end
subgraph DevOps工具层
GitLab
Harbor
GitLab --> |构建镜像| Harbor
end
subgraph 应用层 - K8s集群
Entry --> |负载均衡| K8sMaster
Harbor --> |拉取镜像| K8sMaster
K8sMaster --> K8sNode1
K8sMaster --> K8sNode2
subgraph K8s服务
K8sNode1 --> Gateway
K8sNode1 --> Services[微服务集群]
K8sNode2 --> Websites[前端应用]
end
end
subgraph 中间件层 - Docker部署
Middleware
subgraph 中间件服务
Middleware --> MySQL[(MySQL)]
Middleware --> Redis[(Redis)]
Middleware --> RabbitMQ
Middleware --> ES
Middleware --> Nacos
end
end
subgraph 可观测性层
Prometheus
Grafana
Filebeat
Kibana
Services -.-> |metrics| Prometheus
Services -.-> |logs| Filebeat
Prometheus --> Grafana
Filebeat --> ES
ES --> Kibana
end
Gateway --> Services
Services --> MySQL
Services --> Redis
Services --> Nacos
JumpServer -.-> |SSH管理| K8sMaster
JumpServer -.-> |SSH管理| Middleware
</div><h3 id="22-资源规划">2.2 资源规划</h3>
<table>
<thead>
<tr>
<th>服务器类型</th>
<th>配置建议</th>
<th>数量</th>
<th>用途</th>
<th>说明</th>
</tr>
</thead>
<tbody>
<tr>
<td>Entry节点</td>
<td>2C/4G</td>
<td>1</td>
<td>Nginx负载均衡、外网代理</td>
<td>唯一公网入口</td>
</tr>
<tr>
<td>Middleware</td>
<td>8C/32G</td>
<td>1-2</td>
<td>中间件集群</td>
<td>SSD+HDD混合存储</td>
</tr>
<tr>
<td>K8s Master</td>
<td>4C/8G</td>
<td>3</td>
<td>控制平面</td>
<td>高可用最低3节点</td>
</tr>
<tr>
<td>K8s Worker</td>
<td>8C/32G</td>
<td>2+</td>
<td>应用服务</td>
<td>按业务需求扩展</td>
</tr>
<tr>
<td>JumpServer</td>
<td>4C/8G</td>
<td>1</td>
<td>堡垒机</td>
<td>安全审计</td>
</tr>
</tbody>
</table>
<p><strong>总计</strong>：8台云主机，满足中小规模微服务系统的生产需求。</p>
<h3 id="23-网络规划">2.3 网络规划</h3>
<p>采用三层子网架构，实现网络隔离：</p>
<pre><code>VPC网络: 10.0.0.0/16
├── entry子网: 10.0.10.0/24(Entry、JumpServer)
├── middleware子网: 10.0.20.0/24(中间件节点)
└── k8s子网: 10.0.30.0/24(K8s集群)
K8s内部网络:
├── Pod网段: 172.16.0.0/16 (Calico管理)
└── Service网段: 10.96.0.0/12(kube-proxy管理)
</code></pre>
<p><strong>网络互访规则</strong>：</p>
<table>
<thead>
<tr>
<th>源</th>
<th>目标</th>
<th>说明</th>
</tr>
</thead>
<tbody>
<tr>
<td>Entry</td>
<td>Middleware、K8s</td>
<td>Nginx转发、代理访问</td>
</tr>
<tr>
<td>K8s</td>
<td>Entry、Middleware</td>
<td>访问中间件、外网代理</td>
</tr>
<tr>
<td>Middleware</td>
<td>Entry</td>
<td>外网代理访问</td>
</tr>
<tr>
<td>JumpServer</td>
<td>All</td>
<td>运维管理通道</td>
</tr>
</tbody>
</table>
<p><strong>安全组配置原则</strong>：</p>
<pre><code class="language-bash"># 公网入站(仅Entry节点)
- SSH端口(非22)、80(HTTP)、443(HTTPS)
# 内网互访
- entry子网: 允许与middleware、k8s双向通信
- middleware子网: 允许与entry、k8s通信
- k8s子网: 允许内部互访 + 访问middleware
</code></pre>
<h3 id="24-架构权衡分析">2.4 架构权衡分析</h3>
<table>
<thead>
<tr>
<th>设计决策</th>
<th>优点</th>
<th>风险</th>
<th>缓解措施</th>
</tr>
</thead>
<tbody>
<tr>
<td>3 Master节点</td>
<td>满足高可用要求</td>
<td>-</td>
<td>etcd自动选举</td>
</tr>
<tr>
<td>2 Worker节点</td>
<td>成本可控</td>
<td>资源紧张时扩容</td>
<td>预留扩容空间</td>
</tr>
<tr>
<td>中间件单节点</td>
<td>简化运维、降低成本</td>
<td>单点故障</td>
<td>定时备份、主从可选</td>
</tr>
<tr>
<td>三层子网隔离</td>
<td>安全性高</td>
<td>配置复杂</td>
<td>脚本自动化</td>
</tr>
</tbody>
</table>
<hr>
<h2 id="三技术选型与对比">三、技术选型与对比</h2>
<p>技术选型不是"选最好的"，而是"选最合适的"，以下是三个核心组件的选型分析。</p>
<h3 id="31-容器运行时为什么选择containerd">3.1 容器运行时：为什么选择containerd</h3>
<h4 id="背景kubernetes弃用docker">背景：Kubernetes弃用Docker</h4>
<p>从Kubernetes 1.24开始，正式移除了对Docker的内置支持（dockershim）。这并不意味着Docker镜像不能用了，而是需要选择原生支持CRI接口的容器运行时。</p>
<h4 id="三大容器运行时对比">三大容器运行时对比</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>Docker</th>
<th>containerd</th>
<th>CRI-O</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>定位</strong></td>
<td>完整的容器平台</td>
<td>容器运行时</td>
<td>专为K8s设计的运行时</td>
</tr>
<tr>
<td><strong>与K8s集成</strong></td>
<td>间接（需dockershim）</td>
<td>原生CRI支持</td>
<td>原生CRI支持</td>
</tr>
<tr>
<td><strong>性能</strong></td>
<td>中等</td>
<td>高</td>
<td>高</td>
</tr>
<tr>
<td><strong>资源占用</strong></td>
<td>高（200+ MB）</td>
<td>中（50MB左右）</td>
<td>低（30MB左右）</td>
</tr>
<tr>
<td><strong>调试工具</strong></td>
<td>docker cli</td>
<td>crictl, ctr, nerdctl</td>
<td>crictl</td>
</tr>
<tr>
<td><strong>社区活跃度</strong></td>
<td>高</td>
<td>高</td>
<td>中</td>
</tr>
<tr>
<td><strong>适用场景</strong></td>
<td>开发环境</td>
<td>生产K8s集群</td>
<td>OpenShift环境</td>
</tr>
</tbody>
</table>
<h4 id="架构对比">架构对比</h4>
<p><strong>Docker架构</strong>（多了一层）：</p>
<pre><code>kubelet -> dockershim -> Docker Engine -> containerd -> runc
</code></pre>
<p><strong>containerd架构</strong>（更直接）：</p>
<pre><code>kubelet -> CRI Plugin -> containerd -> runc
</code></pre>
<h4 id="性能数据对比">性能数据对比</h4>
<table>
<thead>
<tr>
<th>测试项</th>
<th>Docker</th>
<th>containerd</th>
<th>提升</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pod启动时间</td>
<td>2.3秒</td>
<td>1.8秒</td>
<td>22%</td>
</tr>
<tr>
<td>内存占用(空载)</td>
<td>210MB</td>
<td>48MB</td>
<td>77%</td>
</tr>
<tr>
<td>CPU使用率(空载)</td>
<td>1.2%</td>
<td>0.3%</td>
<td>75%</td>
</tr>
</tbody>
</table>
<p><strong>结论</strong>：选择containerd，原因是原生CRI支持、性能更好、资源占用更少。</p>
<h3 id="32-网络插件为什么选择calico">3.2 网络插件：为什么选择Calico</h3>
<h4 id="主流网络插件对比">主流网络插件对比</h4>
<table>
<thead>
<tr>
<th>插件</th>
<th>网络模式</th>
<th>性能</th>
<th>NetworkPolicy</th>
<th>复杂度</th>
<th>推荐场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Flannel</strong></td>
<td>VXLAN/Host-GW</td>
<td>中</td>
<td>不支持</td>
<td>简单</td>
<td>学习、开发环境</td>
</tr>
<tr>
<td><strong>Calico</strong></td>
<td>BGP/VXLAN</td>
<td>高</td>
<td>支持</td>
<td>中等</td>
<td>生产环境（首选）</td>
</tr>
<tr>
<td><strong>Weave</strong></td>
<td>VXLAN</td>
<td>低</td>
<td>支持</td>
<td>简单</td>
<td>小型集群</td>
</tr>
<tr>
<td><strong>Cilium</strong></td>
<td>eBPF</td>
<td>高</td>
<td>支持</td>
<td>复杂</td>
<td>新一代方案</td>
</tr>
</tbody>
</table>
<h4 id="calico的两种网络模式">Calico的两种网络模式</h4>
<table>
<thead>
<tr>
<th>模式</th>
<th>工作原理</th>
<th>性能</th>
<th>适用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>BGP模式</strong></td>
<td>节点间通过BGP协议交换路由，数据包直接路由，无封装</td>
<td>最高</td>
<td>同一二层网络、自建机房</td>
</tr>
<tr>
<td><strong>VXLAN模式</strong></td>
<td>数据包通过VXLAN隧道封装传输</td>
<td>中等</td>
<td>跨子网、云环境</td>
</tr>
<tr>
<td><strong>混合模式</strong></td>
<td>同子网BGP，跨子网VXLAN</td>
<td>高</td>
<td>推荐的通用方案</td>
</tr>
</tbody>
</table>
<h4 id="选择calico的理由">选择Calico的理由</h4>
<ol>
<li><strong>性能卓越</strong>：BGP模式无封装开销，性能接近裸金属</li>
<li><strong>NetworkPolicy支持</strong>：支持细粒度的网络访问控制</li>
<li><strong>灵活性</strong>：可根据环境选择BGP或VXLAN模式</li>
<li><strong>生产验证</strong>：大量企业生产环境使用，文档完善</li>
</ol>
<p><strong>推荐配置</strong>：</p>
<pre><code class="language-yaml"># 混合模式：同子网BGP，跨子网VXLAN
calicoNetwork:
bgp: Enabled
ipPools:
- cidr: 172.16.0.0/16
encapsulation: VXLANCrossSubnet# 关键配置
natOutgoing: Enabled
</code></pre>
<h3 id="33-ingress-controller为什么选择traefik">3.3 Ingress Controller：为什么选择Traefik</h3>
<h4 id="主流ingress-controller对比">主流Ingress Controller对比</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>Nginx Ingress</th>
<th>Traefik</th>
<th>Istio Gateway</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>性能</strong></td>
<td>高</td>
<td>中高</td>
<td>中</td>
</tr>
<tr>
<td><strong>配置方式</strong></td>
<td>Annotation</td>
<td>Annotation/CRD</td>
<td>CRD</td>
</tr>
<tr>
<td><strong>动态配置</strong></td>
<td>需重载</td>
<td>热更新</td>
<td>热更新</td>
</tr>
<tr>
<td><strong>Let's Encrypt</strong></td>
<td>需插件</td>
<td>内置</td>
<td>需cert-manager</td>
</tr>
<tr>
<td><strong>UI Dashboard</strong></td>
<td>无</td>
<td>内置</td>
<td>Kiali</td>
</tr>
<tr>
<td><strong>学习曲线</strong></td>
<td>低</td>
<td>中</td>
<td>高</td>
</tr>
<tr>
<td><strong>适用场景</strong></td>
<td>追求性能</td>
<td>平衡易用性</td>
<td>服务网格</td>
</tr>
</tbody>
</table>
<h4 id="性能对比数据">性能对比数据</h4>
<pre><code>压测环境：1000并发，持续10分钟
Nginx Ingress:45000 QPS, P95延迟 12ms
Traefik: 38000 QPS, P95延迟 15ms
Istio Gateway:32000 QPS, P95延迟 22ms
结论：Nginx性能最好，但差距不大
</code></pre>
<h4 id="选择traefik的理由">选择Traefik的理由</h4>
<ol>
<li><strong>动态配置热更新</strong>：配置变更无需重载，零中断</li>
<li><strong>Let's Encrypt自动化</strong>：内置ACME客户端，自动申请和续期证书</li>
<li><strong>可视化Dashboard</strong>：实时查看流量和路由配置</li>
<li><strong>中间件机制</strong>：可复用的配置组件（限流、认证等）</li>
</ol>
<p>对于大多数应用，性能已经足够，Traefik的易用性优势值得这个性能差距。</p>
<hr>
<h2 id="四devops体系设计">四、DevOps体系设计</h2>
<p>K8s只是基础设施，要实现真正的持续交付，还需要完整的DevOps工具链。本节介绍CI/CD、镜像管理、监控和日志的架构设计。</p>
<h3 id="41-devops全景图">4.1 DevOps全景图</h3>
<div class="mermaid">graph LR
subgraph 开发阶段
Dev[开发者] --> |push| GitLab
end
subgraph CI阶段
GitLab --> |触发| Pipeline
Pipeline --> |构建| Build
Build --> |打包| Docker
Docker --> |推送| Harbor
end
subgraph CD阶段
Harbor --> |拉取| K8s
K8s --> |部署| App[应用服务]
end
subgraph 运维阶段
App --> |指标| Prometheus
App --> |日志| Filebeat
Prometheus --> Grafana
Filebeat --> ES
ES --> Kibana
end
</div><p><strong>DevOps流程说明</strong>：</p>
<table>
<thead>
<tr>
<th>阶段</th>
<th>工具</th>
<th>职责</th>
<th>触发条件</th>
</tr>
</thead>
<tbody>
<tr>
<td>代码管理</td>
<td>GitLab</td>
<td>版本控制、代码审查</td>
<td>开发者提交</td>
</tr>
<tr>
<td>持续集成</td>
<td>GitLab CI</td>
<td>编译、测试、构建镜像</td>
<td>Push/MR事件</td>
</tr>
<tr>
<td>镜像管理</td>
<td>Harbor</td>
<td>存储、扫描、分发镜像</td>
<td>镜像推送</td>
</tr>
<tr>
<td>持续部署</td>
<td>kubectl/Helm</td>
<td>应用发布、滚动更新</td>
<td>手动/自动触发</td>
</tr>
<tr>
<td>监控告警</td>
<td>Prometheus + Grafana</td>
<td>指标采集、可视化、告警</td>
<td>持续运行</td>
</tr>
<tr>
<td>日志管理</td>
<td>Filebeat + ES + Kibana</td>
<td>日志收集、存储、分析</td>
<td>持续运行</td>
</tr>
</tbody>
</table>
<h3 id="42-cicd架构设计">4.2 CI/CD架构设计</h3>
<h4 id="为什么需要cicd">为什么需要CI/CD</h4>
<p><strong>手工部署的问题</strong>：</p>
<table>
<thead>
<tr>
<th>问题</th>
<th>具体表现</th>
<th>后果</th>
</tr>
</thead>
<tbody>
<tr>
<td>效率低</td>
<td>每次部署需要30分钟+</td>
<td>发布频率受限，无法快速迭代</td>
</tr>
<tr>
<td>易出错</td>
<td>漏步骤、配置错误、环境不一致</td>
<td>线上故障频发</td>
</tr>
<tr>
<td>不可追溯</td>
<td>谁部署的？什么版本？</td>
<td>问题定位困难</td>
</tr>
<tr>
<td>无法回滚</td>
<td>出问题只能重新部署</td>
<td>故障恢复时间长</td>
</tr>
</tbody>
</table>
<p><strong>CI/CD带来的改变</strong>：</p>
<pre><code>代码提交 -> 自动构建 -> 自动测试 -> 自动部署 -> 自动监控
| | | | |
1分钟 5分钟 3分钟 2分钟 持续
总计：从提交到上线 ~11分钟，全程自动化，可追溯
</code></pre>
<h4 id="cicd工具选型对比">CI/CD工具选型对比</h4>
<table>
<thead>
<tr>
<th>工具</th>
<th>优势</th>
<th>劣势</th>
<th>适用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Jenkins</strong></td>
<td>插件丰富、社区成熟</td>
<td>配置复杂、UI老旧、维护成本高</td>
<td>复杂定制需求</td>
</tr>
<tr>
<td><strong>GitLab CI</strong></td>
<td>与GitLab深度集成、YAML配置、内置模板</td>
<td>依赖GitLab平台</td>
<td>GitLab用户首选</td>
</tr>
<tr>
<td><strong>GitHub Actions</strong></td>
<td>与GitHub集成、市场丰富</td>
<td>私有部署受限</td>
<td>GitHub用户</td>
</tr>
<tr>
<td><strong>Tekton</strong></td>
<td>K8s原生、灵活</td>
<td>学习曲线陡、生态较新</td>
<td>云原生深度用户</td>
</tr>
<tr>
<td><strong>Argo CD</strong></td>
<td>GitOps理念、声明式</td>
<td>只负责CD，需配合CI工具</td>
<td>GitOps实践</td>
</tr>
</tbody>
</table>
<p><strong>选择GitLab CI的理由</strong>：</p>
<ol>
<li><strong>一站式平台</strong>：代码、CI/CD、Issue、Wiki集成在一起</li>
<li><strong>配置即代码</strong>：<code>.gitlab-ci.yml</code>版本化管理</li>
<li><strong>模板复用</strong>：<code>include</code>机制实现配置复用</li>
<li><strong>可视化Pipeline</strong>：直观查看构建状态和日志</li>
<li><strong>私有部署</strong>：完全可控，数据不外泄</li>
</ol>
<h4 id="流水线设计原则">流水线设计原则</h4>
<p><strong>模板化设计</strong>：</p>
<pre><code>项目A/.gitlab-ci.yml
项目B/.gitlab-ci.yml -----> 公共模板库
项目C/.gitlab-ci.yml ├── java-template.yml
├── node-template.yml
└── docker-template.yml
</code></pre>
<p><strong>好处</strong>：</p>
<ul>
<li>统一构建规范，减少重复配置</li>
<li>修改模板即可批量更新所有项目</li>
<li>新项目快速接入，只需include模板</li>
</ul>
<p><strong>智能构建检测</strong>：</p>
<div class="mermaid">graph TD
A[代码提交] --> B{检测变更类型}
B --> |Java文件变更| C[执行Maven构建]
B --> |前端文件变更| D[执行npm构建]
B --> |配置文件变更| E[仅部署，跳过构建]
B --> |文档变更| F[跳过Pipeline]
</div><p><strong>设计要点</strong>：</p>
<ul>
<li>根据变更文件类型决定执行哪些阶段</li>
<li>避免无意义的全量构建，节省资源和时间</li>
<li>支持手动触发强制全量构建</li>
</ul>
<h3 id="43-镜像管理策略">4.3 镜像管理策略</h3>
<h4 id="为什么需要私有镜像仓库">为什么需要私有镜像仓库</h4>
<table>
<thead>
<tr>
<th>场景</th>
<th>公共仓库(DockerHub)</th>
<th>私有仓库(Harbor)</th>
</tr>
</thead>
<tbody>
<tr>
<td>拉取速度</td>
<td>受网络影响，可能很慢</td>
<td>内网访问，毫秒级</td>
</tr>
<tr>
<td>镜像安全</td>
<td>公开可见</td>
<td>私有隔离，权限控制</td>
</tr>
<tr>
<td>安全扫描</td>
<td>付费功能</td>
<td>内置Trivy扫描</td>
</tr>
<tr>
<td>可用性</td>
<td>依赖外网</td>
<td>内网独立运行</td>
</tr>
<tr>
<td>限流</td>
<td>免费版有拉取限制</td>
<td>无限制</td>
</tr>
</tbody>
</table>
<h4 id="镜像仓库选型对比">镜像仓库选型对比</h4>
<table>
<thead>
<tr>
<th>仓库</th>
<th>功能</th>
<th>复杂度</th>
<th>适用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Docker Registry</strong></td>
<td>基础镜像存储</td>
<td>低</td>
<td>简单场景</td>
</tr>
<tr>
<td><strong>Harbor</strong></td>
<td>企业级功能（扫描、复制、RBAC）</td>
<td>中</td>
<td>生产环境推荐</td>
</tr>
<tr>
<td><strong>Nexus</strong></td>
<td>多类型制品（Maven+Docker+npm）</td>
<td>中</td>
<td>统一制品管理</td>
</tr>
<tr>
<td><strong>JFrog Artifactory</strong></td>
<td>全功能企业级</td>
<td>高</td>
<td>大型企业</td>
</tr>
</tbody>
</table>
<p><strong>选择Harbor的理由</strong>：</p>
<ol>
<li><strong>CNCF毕业项目</strong>：社区活跃，持续演进</li>
<li><strong>安全扫描</strong>：内置Trivy，自动检测CVE漏洞</li>
<li><strong>镜像签名</strong>：Notary支持，确保镜像完整性</li>
<li><strong>复制策略</strong>：支持多数据中心镜像同步</li>
<li><strong>RBAC权限</strong>：项目级别的精细权限控制</li>
<li><strong>Web UI</strong>：友好的管理界面</li>
</ol>
<h4 id="镜像版本策略">镜像版本策略</h4>
<table>
<thead>
<tr>
<th>标签类型</th>
<th>示例</th>
<th>用途</th>
<th>是否可变</th>
</tr>
</thead>
<tbody>
<tr>
<td>Git SHA</td>
<td><code>app:a1b2c3d</code></td>
<td>精确追溯到提交</td>
<td>不可变</td>
</tr>
<tr>
<td>语义版本</td>
<td><code>app:1.2.3</code></td>
<td>正式发布版本</td>
<td>不可变</td>
</tr>
<tr>
<td>分支标签</td>
<td><code>app:develop</code></td>
<td>最新开发版</td>
<td>可变</td>
</tr>
<tr>
<td>latest</td>
<td><code>app:latest</code></td>
<td>最新版本</td>
<td>可变，不推荐生产使用</td>
</tr>
</tbody>
</table>
<p><strong>推荐做法</strong>：</p>
<ul>
<li>生产环境使用Git SHA或语义版本，确保可追溯</li>
<li>测试环境可使用分支标签</li>
<li>禁止在生产环境使用<code>latest</code>标签</li>
</ul>
<h3 id="44-监控体系设计">4.4 监控体系设计</h3>
<h4 id="可观测性三大支柱">可观测性三大支柱</h4>
<pre><code> 可观测性
|
+---------------+---------------+
| | |
指标 日志 追踪
(Metrics) (Logs) (Traces)
| | |
Prometheus ELK/Loki Jaeger
+ Grafana /Zipkin
</code></pre>
<table>
<thead>
<tr>
<th>支柱</th>
<th>回答的问题</th>
<th>工具</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>指标(Metrics)</strong></td>
<td>系统现在怎么样？趋势如何？</td>
<td>Prometheus + Grafana</td>
</tr>
<tr>
<td><strong>日志(Logs)</strong></td>
<td>发生了什么？错误详情？</td>
<td>ELK / Loki</td>
</tr>
<tr>
<td><strong>追踪(Traces)</strong></td>
<td>请求经过了哪些服务？瓶颈在哪？</td>
<td>Jaeger / Zipkin</td>
</tr>
</tbody>
</table>
<p><strong>本方案聚焦</strong>：指标和日志（覆盖90%监控需求）</p>
<h4 id="监控方案对比">监控方案对比</h4>
<table>
<thead>
<tr>
<th>方案</th>
<th>架构</th>
<th>优势</th>
<th>劣势</th>
<th>适用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Prometheus + Grafana</strong></td>
<td>拉取式</td>
<td>云原生标准、生态丰富</td>
<td>长期存储需额外方案</td>
<td>K8s环境首选</td>
</tr>
<tr>
<td><strong>Zabbix</strong></td>
<td>推送式</td>
<td>功能全面、历史悠久</td>
<td>配置复杂、不够云原生</td>
<td>传统运维</td>
</tr>
<tr>
<td><strong>Datadog/New Relic</strong></td>
<td>SaaS</td>
<td>开箱即用、免运维</td>
<td>成本高、数据外泄</td>
<td>预算充足团队</td>
</tr>
<tr>
<td><strong>VictoriaMetrics</strong></td>
<td>兼容Prometheus</td>
<td>性能更高、长期存储</td>
<td>社区较小</td>
<td>大规模场景</td>
</tr>
</tbody>
</table>
<p><strong>选择Prometheus + Grafana的理由</strong>：</p>
<ol>
<li><strong>K8s原生集成</strong>：ServiceMonitor自动发现</li>
<li><strong>PromQL强大</strong>：灵活的查询语言</li>
<li><strong>Grafana生态</strong>：丰富的Dashboard模板</li>
<li><strong>Alertmanager</strong>：灵活的告警路由</li>
<li><strong>社区标准</strong>：几乎所有云原生组件都暴露Prometheus指标</li>
</ol>
<h4 id="监控分层设计">监控分层设计</h4>
<pre><code>+------------------+------------------------------------------+
| 业务监控 |订单量、成功率、响应时间、业务异常 |
+------------------+------------------------------------------+
| 应用监控 |JVM指标、HTTP请求、数据库连接池 |
+------------------+------------------------------------------+
| K8s监控 |Pod状态、资源使用、Deployment健康 |
+------------------+------------------------------------------+
| 基础设施监控 |CPU、内存、磁盘、网络、进程 |
+------------------+------------------------------------------+
</code></pre>
<table>
<thead>
<tr>
<th>层级</th>
<th>关键指标</th>
<th>数据来源</th>
</tr>
</thead>
<tbody>
<tr>
<td>基础设施</td>
<td>CPU/内存/磁盘/网络</td>
<td>Node Exporter</td>
</tr>
<tr>
<td>K8s层</td>
<td>Pod/Deployment/Service状态</td>
<td>kube-state-metrics</td>
</tr>
<tr>
<td>应用层</td>
<td>JVM/HTTP/DB连接</td>
<td>应用内置metrics端点</td>
</tr>
<tr>
<td>业务层</td>
<td>订单/支付/用户行为</td>
<td>自定义metrics</td>
</tr>
</tbody>
</table>
<h3 id="45-日志体系设计">4.5 日志体系设计</h3>
<h4 id="日志收集方案对比">日志收集方案对比</h4>
<table>
<thead>
<tr>
<th>方案</th>
<th>架构</th>
<th>优势</th>
<th>劣势</th>
<th>适用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>ELK Stack</strong></td>
<td>Filebeat -> ES -> Kibana</td>
<td>功能强大、查询灵活</td>
<td>资源消耗大</td>
<td>中大规模</td>
</tr>
<tr>
<td><strong>Loki + Grafana</strong></td>
<td>Promtail -> Loki -> Grafana</td>
<td>轻量、与Prometheus集成</td>
<td>不支持全文索引</td>
<td>轻量场景</td>
</tr>
<tr>
<td><strong>Fluentd</strong></td>
<td>通用收集器</td>
<td>插件丰富、灵活</td>
<td>配置复杂</td>
<td>复杂路由需求</td>
</tr>
</tbody>
</table>
<p><strong>选型建议</strong>：</p>
<table>
<thead>
<tr>
<th>团队规模</th>
<th>日志量</th>
<th>推荐方案</th>
<th>理由</th>
</tr>
</thead>
<tbody>
<tr>
<td>小</td>
<td><10GB/天</td>
<td>Loki</td>
<td>轻量、与Grafana统一</td>
</tr>
<tr>
<td>中</td>
<td>10-100GB/天</td>
<td>ELK</td>
<td>功能全面、查询强大</td>
</tr>
<tr>
<td>大</td>
<td>>100GB/天</td>
<td>ELK + 冷热分离</td>
<td>性能和成本平衡</td>
</tr>
</tbody>
</table>
<h4 id="日志收集架构">日志收集架构</h4>
<div class="mermaid">graph LR
subgraph K8s集群
Pod1 --> |stdout| Filebeat1
Pod2 --> |stdout| Filebeat1
Pod3 --> |stdout| Filebeat2
end
subgraph 日志平台
Filebeat1 --> ES
Filebeat2 --> ES
ES --> Kibana
end
</div><p><strong>设计要点</strong>：</p>
<ol>
<li><strong>DaemonSet部署</strong>：每个节点一个Filebeat实例</li>
<li><strong>采集stdout</strong>：应用日志输出到标准输出</li>
<li><strong>结构化日志</strong>：JSON格式，便于解析和查询</li>
<li><strong>索引策略</strong>：按日期分索引，便于清理和管理</li>
<li><strong>保留策略</strong>：根据合规要求设置保留天数</li>
</ol>
<hr>
<h2 id="五中间件体系设计">五、中间件体系设计</h2>
<p>微服务架构离不开中间件的支撑，具体的选择通常依赖于后端的整体架构，以下是我们的选择。</p>
<h3 id="51-中间件全景图">5.1 中间件全景图</h3>
<div class="mermaid">graph TB
subgraph 应用层
Gateway
Services[微服务集群]
end
subgraph 中间件层
MySQL[(MySQL<br/>数据存储)]
Redis[(Redis<br/>缓存)]
ES[(Elasticsearch<br/>搜索/日志)]
RabbitMQ
Nacos
MinIO
end
Gateway --> Services
Services --> MySQL
Services --> Redis
Services --> ES
Services --> RabbitMQ
Services --> Nacos
Services --> MinIO
</div><p><strong>中间件职责</strong>：</p>
<table>
<thead>
<tr>
<th>中间件</th>
<th>职责</th>
<th>应用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td>MySQL</td>
<td>关系型数据存储</td>
<td>业务数据持久化</td>
</tr>
<tr>
<td>Redis</td>
<td>缓存、分布式锁</td>
<td>热点数据缓存、会话管理</td>
</tr>
<tr>
<td>Elasticsearch</td>
<td>全文搜索、日志存储</td>
<td>商品搜索、日志分析</td>
</tr>
<tr>
<td>RabbitMQ</td>
<td>异步消息、解耦</td>
<td>订单处理、通知推送</td>
</tr>
<tr>
<td>Nacos</td>
<td>配置管理、服务发现</td>
<td>动态配置、服务注册</td>
</tr>
<tr>
<td>MinIO</td>
<td>对象存储</td>
<td>图片、文件存储</td>
</tr>
</tbody>
</table>
<h3 id="52-中间件选型分析">5.2 中间件选型分析</h3>
<h4 id="521-数据库mysql">5.2.1 数据库：MySQL</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>MySQL</th>
<th>PostgreSQL</th>
<th>云RDS</th>
</tr>
</thead>
<tbody>
<tr>
<td>生态成熟度</td>
<td>高</td>
<td>高</td>
<td>高</td>
</tr>
<tr>
<td>运维复杂度</td>
<td>中</td>
<td>中</td>
<td>低</td>
</tr>
<tr>
<td>成本</td>
<td>低</td>
<td>低</td>
<td>高</td>
</tr>
<tr>
<td>团队熟悉度</td>
<td>高</td>
<td>中</td>
<td>高</td>
</tr>
</tbody>
</table>
<p><strong>选择MySQL的理由</strong>：</p>
<ul>
<li>团队熟悉，运维经验丰富</li>
<li>生态成熟，工具链完善</li>
<li>后续可平滑迁移到云RDS</li>
</ul>
<h4 id="522-缓存redis">5.2.2 缓存：Redis</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>Redis</th>
<th>Memcached</th>
<th>云Redis</th>
</tr>
</thead>
<tbody>
<tr>
<td>数据结构</td>
<td>丰富（String/Hash/List/Set/ZSet）</td>
<td>简单（Key-Value）</td>
<td>丰富</td>
</tr>
<tr>
<td>持久化</td>
<td>支持（RDB/AOF）</td>
<td>不支持</td>
<td>支持</td>
</tr>
<tr>
<td>集群模式</td>
<td>支持</td>
<td>需客户端分片</td>
<td>支持</td>
</tr>
<tr>
<td>成本</td>
<td>低</td>
<td>低</td>
<td>高</td>
</tr>
</tbody>
</table>
<p><strong>选择Redis的理由</strong>：</p>
<ul>
<li>数据结构丰富，适用场景广</li>
<li>支持持久化，数据更安全</li>
<li>原生支持集群模式</li>
</ul>
<h4 id="523-消息队列rabbitmq">5.2.3 消息队列：RabbitMQ</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>RabbitMQ</th>
<th>Kafka</th>
<th>RocketMQ</th>
</tr>
</thead>
<tbody>
<tr>
<td>吞吐量</td>
<td>中（万级）</td>
<td>高（百万级）</td>
<td>高（十万级）</td>
</tr>
<tr>
<td>延迟</td>
<td>低（毫秒）</td>
<td>中（毫秒）</td>
<td>低（毫秒）</td>
</tr>
<tr>
<td>功能完整性</td>
<td>高</td>
<td>中</td>
<td>高</td>
</tr>
<tr>
<td>运维复杂度</td>
<td>低</td>
<td>高</td>
<td>中</td>
</tr>
</tbody>
</table>
<p><strong>选择RabbitMQ的理由</strong>：</p>
<ul>
<li>功能完整，支持多种消息模式</li>
<li>管理界面友好，运维简单</li>
<li>延迟低，适合业务消息</li>
</ul>
<h4 id="524-配置中心nacos">5.2.4 配置中心：Nacos</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>Nacos</th>
<th>Apollo</th>
<th>Consul</th>
</tr>
</thead>
<tbody>
<tr>
<td>配置管理</td>
<td>支持</td>
<td>支持</td>
<td>支持</td>
</tr>
<tr>
<td>服务发现</td>
<td>支持</td>
<td>不支持</td>
<td>支持</td>
</tr>
<tr>
<td>架构复杂度</td>
<td>低</td>
<td>高</td>
<td>中</td>
</tr>
<tr>
<td>社区活跃度</td>
<td>高</td>
<td>中</td>
<td>高</td>
</tr>
</tbody>
</table>
<p><strong>选择Nacos的理由</strong>：</p>
<ul>
<li>配置管理 + 服务发现一体化</li>
<li>架构简单，部署方便</li>
<li>阿里开源，与Spring Cloud Alibaba深度集成</li>
</ul>
<h4 id="525-对象存储minio">5.2.5 对象存储：MinIO</h4>
<table>
<thead>
<tr>
<th>对比项</th>
<th>MinIO</th>
<th>云OSS</th>
<th>FastDFS</th>
</tr>
</thead>
<tbody>
<tr>
<td>S3兼容</td>
<td>完全兼容</td>
<td>兼容</td>
<td>不兼容</td>
</tr>
<tr>
<td>私有部署</td>
<td>支持</td>
<td>不支持</td>
<td>支持</td>
</tr>
<tr>
<td>运维复杂度</td>
<td>低</td>
<td>无需运维</td>
<td>高</td>
</tr>
<tr>
<td>成本</td>
<td>低</td>
<td>按量付费</td>
<td>低</td>
</tr>
</tbody>
</table>
<p><strong>选择MinIO的理由</strong>：</p>
<ul>
<li>S3 API兼容，后续可无缝迁移到云OSS</li>
<li>私有部署，数据可控</li>
<li>轻量级，单节点即可运行</li>
</ul>
<h3 id="53-部署策略选择">5.3 部署策略选择</h3>
<h4 id="部署方式对比">部署方式对比</h4>
<table>
<thead>
<tr>
<th>部署方式</th>
<th>优点</th>
<th>缺点</th>
<th>适用阶段</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Docker单机</strong></td>
<td>简单、快速、成本低</td>
<td>无高可用、容量有限</td>
<td>MVP/初创期</td>
</tr>
<tr>
<td><strong>K8s StatefulSet</strong></td>
<td>统一管理、自动调度</td>
<td>运维复杂、性能损耗</td>
<td>中大规模</td>
</tr>
<tr>
<td><strong>主从/集群</strong></td>
<td>高可用、读写分离</td>
<td>运维复杂、成本增加</td>
<td>成长期</td>
</tr>
<tr>
<td><strong>云厂商托管</strong></td>
<td>免运维、高可用</td>
<td>成本高、厂商绑定</td>
<td>成熟期</td>
</tr>
</tbody>
</table>
<h4 id="当前选择docker单机部署">当前选择：Docker单机部署</h4>
<p><strong>选择理由</strong>：</p>
<ol>
<li><strong>项目阶段</strong>：初期业务量不大，单机足够承载</li>
<li><strong>运维简单</strong>：Docker Compose一键部署，易于管理</li>
<li><strong>成本可控</strong>：无需额外购买云服务</li>
<li><strong>灵活性</strong>：后续可根据需要平滑升级</li>
</ol>
<h3 id="54-演进路径规划">5.4 演进路径规划</h3>
<div class="mermaid">graph LR
A[阶段一<br/>Docker单机] --> B[阶段二<br/>主从/集群]
B --> C[阶段三<br/>云托管服务]
A --> |业务增长| B
B --> |规模扩大| C
</div><h4 id="阶段一docker单机当前">阶段一：Docker单机（当前）</h4>
<ul>
<li><strong>部署方式</strong>：Docker Compose</li>
<li><strong>高可用</strong>：定时备份 + 快速恢复</li>
<li><strong>适用场景</strong>：日活<1万、数据量<100GB</li>
</ul>
<h4 id="阶段二主从集群">阶段二：主从/集群</h4>
<ul>
<li><strong>MySQL</strong>：主从复制 / MGR集群</li>
<li><strong>Redis</strong>：哨兵模式 / Cluster集群</li>
<li><strong>ES</strong>：多节点集群</li>
<li><strong>适用场景</strong>：日活1-10万、数据量100GB-1TB</li>
</ul>
<h4 id="阶段三云厂商托管">阶段三：云厂商托管</h4>
<ul>
<li><strong>云RDS</strong>：MySQL托管服务</li>
<li><strong>云Redis</strong>：Redis托管服务</li>
<li><strong>云ES</strong>：Elasticsearch托管服务</li>
<li><strong>适用场景</strong>：日活>10万、追求高可用和免运维</li>
</ul>
<p><strong>演进原则</strong>：</p>
<ol>
<li><strong>按需升级</strong>：业务增长驱动，不过度设计</li>
<li><strong>平滑迁移</strong>：选型时考虑兼容性，降低迁移成本</li>
<li><strong>数据安全</strong>：每次迁移前做好备份和回滚方案</li>
</ol>
<hr>
<h2 id="六k8s核心概念精要">六、K8s核心概念精要</h2>
<h3 id="61-核心资源关系图">6.1 核心资源关系图</h3>
<div class="mermaid">graph TB
subgraph 用户访问
User[用户] --> Ingress
end
subgraph K8s集群
Ingress --> Service
Service --> Pod1
Service --> Pod2
Service --> Pod3
Deployment --> |管理| Pod1
Deployment --> |管理| Pod2
Deployment --> |管理| Pod3
ConfigMap -.-> Pod1
Secret -.-> Pod1
end
</div><h3 id="62-核心资源说明">6.2 核心资源说明</h3>
<table>
<thead>
<tr>
<th>资源</th>
<th>作用</th>
<th>类比</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Pod</strong></td>
<td>最小部署单元，包含一个或多个容器</td>
<td>一个应用实例</td>
</tr>
<tr>
<td><strong>Deployment</strong></td>
<td>声明式管理Pod，支持滚动更新和回滚</td>
<td>应用版本管理器</td>
</tr>
<tr>
<td><strong>Service</strong></td>
<td>为Pod提供稳定的访问入口和负载均衡</td>
<td>内部DNS+负载均衡器</td>
</tr>
<tr>
<td><strong>Ingress</strong></td>
<td>7层HTTP路由，暴露服务给外部访问</td>
<td>反向代理</td>
</tr>
<tr>
<td><strong>ConfigMap</strong></td>
<td>存储非敏感配置</td>
<td>配置文件</td>
</tr>
<tr>
<td><strong>Secret</strong></td>
<td>存储敏感信息（密码、证书）</td>
<td>加密的配置文件</td>
</tr>
</tbody>
</table>
<h3 id="63-service的四种类型">6.3 Service的四种类型</h3>
<table>
<thead>
<tr>
<th>类型</th>
<th>说明</th>
<th>使用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>ClusterIP</strong></td>
<td>集群内部访问（默认）</td>
<td>微服务间调用</td>
</tr>
<tr>
<td><strong>NodePort</strong></td>
<td>通过节点IP+端口访问</td>
<td>开发测试、简单场景</td>
</tr>
<tr>
<td><strong>LoadBalancer</strong></td>
<td>云厂商负载均衡器</td>
<td>公有云环境</td>
</tr>
<tr>
<td><strong>ExternalName</strong></td>
<td>返回外部服务的CNAME</td>
<td>访问外部服务</td>
</tr>
</tbody>
</table>
<h3 id="64-kube-proxy工作模式">6.4 kube-proxy工作模式</h3>
<p>kube-proxy负责实现Service的网络转发规则：</p>
<table>
<thead>
<tr>
<th>模式</th>
<th>实现方式</th>
<th>性能</th>
<th>推荐场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>iptables</strong></td>
<td>iptables规则</td>
<td>中</td>
<td>中小集群（默认）</td>
</tr>
<tr>
<td><strong>ipvs</strong></td>
<td>IPVS负载均衡</td>
<td>高</td>
<td>大规模集群（推荐）</td>
</tr>
</tbody>
</table>
<p><strong>ipvs模式优势</strong>：</p>
<ul>
<li>规则查找O(1)复杂度，性能更稳定</li>
<li>支持多种负载均衡算法（rr、wrr、lc等）</li>
<li>支持会话保持</li>
</ul>
<h3 id="65-pod调度机制">6.5 Pod调度机制</h3>
<p>调度器决定Pod运行在哪个节点：</p>
<pre><code>Pod创建请求
↓
过滤阶段（排除不满足条件的节点）
- 资源不足
- 节点污点
- 亲和性规则不满足
↓
打分阶段（对候选节点评分）
- 资源均衡度
- 镜像本地性
- 亲和性权重
↓
选择得分最高的节点
</code></pre>
<p><strong>常用调度策略</strong>：</p>
<table>
<thead>
<tr>
<th>策略</th>
<th>配置方式</th>
<th>场景</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>NodeSelector</strong></td>
<td>标签选择器</td>
<td>简单的节点选择</td>
</tr>
<tr>
<td><strong>NodeAffinity</strong></td>
<td>亲和性规则</td>
<td>复杂的节点选择</td>
</tr>
<tr>
<td><strong>PodAffinity</strong></td>
<td>Pod亲和性</td>
<td>Pod靠近部署</td>
</tr>
<tr>
<td><strong>PodAntiAffinity</strong></td>
<td>Pod反亲和性</td>
<td>Pod分散部署</td>
</tr>
<tr>
<td><strong>Taints/Tolerations</strong></td>
<td>污点和容忍</td>
<td>专用节点、节点维护</td>
</tr>
</tbody>
</table>
<hr>
<h2 id="七总结与最佳实践">七、总结与最佳实践</h2>
<h3 id="71-架构设计核心原则">7.1 架构设计核心原则</h3>
<p><strong>基础设施层</strong>：</p>
<ol>
<li><strong>高可用优先</strong>：Master至少3节点（可容忍1个节点故障），应用至少2副本</li>
<li><strong>网络隔离</strong>：分层子网，最小化暴露面</li>
<li><strong>预留扩展空间</strong>：资源规划留有余量</li>
</ol>
<p><strong>中间件层</strong>：<br>
4. <strong>简单优先</strong>：初期Docker单机，按需演进<br>
5. <strong>兼容性考量</strong>：选型时考虑后续迁移成本<br>
6. <strong>数据安全</strong>：定时备份，快速恢复能力</p>
<p><strong>DevOps层</strong>：<br>
7. <strong>自动化优先</strong>：能自动化的绝不手工操作<br>
8. <strong>配置即代码</strong>：CI/CD配置、K8s YAML全部版本化<br>
9. <strong>模板复用</strong>：通过模板统一规范，减少重复</p>
<p><strong>运维层</strong>：<br>
10. <strong>监控先行</strong>：先部署监控，再部署应用<br>
11. <strong>可观测性</strong>：指标、日志、追踪三位一体<br>
12. <strong>故障预案</strong>：提前准备回滚方案</p>
<h3 id="72-技术选型检查清单">7.2 技术选型检查清单</h3>
<table>
<thead>
<tr>
<th>层级</th>
<th>组件</th>
<th>推荐选型</th>
<th>选型依据</th>
</tr>
</thead>
<tbody>
<tr>
<td>容器</td>
<td>运行时</td>
<td>containerd</td>
<td>原生CRI、性能好、轻量</td>
</tr>
<tr>
<td>网络</td>
<td>CNI插件</td>
<td>Calico</td>
<td>性能高、NetworkPolicy支持</td>
</tr>
<tr>
<td>网络</td>
<td>Ingress</td>
<td>Traefik</td>
<td>热更新、Let's Encrypt、Dashboard</td>
</tr>
<tr>
<td>中间件</td>
<td>数据库</td>
<td>MySQL 8.x</td>
<td>生态成熟、团队熟悉</td>
</tr>
<tr>
<td>中间件</td>
<td>缓存</td>
<td>Redis 7.x</td>
<td>数据结构丰富、持久化</td>
</tr>
<tr>
<td>中间件</td>
<td>消息队列</td>
<td>RabbitMQ</td>
<td>功能完整、运维简单</td>
</tr>
<tr>
<td>中间件</td>
<td>配置中心</td>
<td>Nacos</td>
<td>配置+服务发现一体化</td>
</tr>
<tr>
<td>DevOps</td>
<td>CI/CD</td>
<td>GitLab CI</td>
<td>与GitLab集成、模板化、可视化</td>
</tr>
<tr>
<td>DevOps</td>
<td>镜像仓库</td>
<td>Harbor</td>
<td>企业级、安全扫描、RBAC</td>
</tr>
<tr>
<td>监控</td>
<td>指标</td>
<td>Prometheus + Grafana</td>
<td>云原生标准、生态丰富</td>
</tr>
<tr>
<td>监控</td>
<td>日志</td>
<td>ELK / Loki</td>
<td>根据规模选择</td>
</tr>
</tbody>
</table>
<h3 id="73-系列文章">7.3 系列文章</h3>
<p>本文介绍了K8s集群的架构设计、技术选型、DevOps体系设计以及中间件体系设计。</p>
<p><strong>下一篇《部署实践篇》</strong>将详细介绍具体实施步骤：</p>
<ul>
<li><strong>环境准备</strong>：网络规划、基础设施初始化、系统优化</li>
<li><strong>中间件部署</strong>：Docker Compose部署MySQL、Redis等</li>
<li><strong>集群搭建</strong>：kubeadm初始化、Calico网络、Traefik Ingress</li>
<li><strong>CI/CD搭建</strong>：Harbor配置、GitLab CI模板设计</li>
<li><strong>监控部署</strong>：Prometheus + Grafana、告警规则配置</li>
<li><strong>故障排查</strong>：常见问题速查表</li>
</ul>
<p><strong>附篇《故障排查实战》</strong>通过真实案例介绍：</p>
<ul>
<li><strong>典型案例</strong>：跨节点Pod通信504问题的完整排查过程</li>
<li><strong>排查方法论</strong>：分层诊断法、工具选择</li>
<li><strong>安全组配置</strong>：云环境K8s集群安全组配置清单</li>
</ul>
<hr>
<p><strong>关键词</strong>: Kubernetes、架构设计、技术选型、DevOps、云原生</p><br><br>
来源：https://www.cnblogs.com/gOODiDEA/p/19315714
頁:
[1]