企业官网建设流程全解析

简介：基于K8S容器云平台的微服务部署方案是一份面向企业架构师、运维人员及K8S/OpenShift实践者的解决方案文档。内容围绕微服务化后的调度、负载均衡、集群管理与有状态数据等挑战，重点梳理了容器云部署框架、权限管理、多租户隔离及日志监控四大关键环节，并结合DMZ与内网双环境隔离、OCP的project租户模型、EFK日志平台与监控组件给出具体落地建议。资源为单个docx文件，包体大小约417KB，便于阅读与归档；目前已有497人学习下载。文档基于社区专家交流整理，既有框架性设计思路，也包含认证鉴权、Router隔离、nodeSelector资源池划分、日志持久化等实操细节，对规划企业级容器云微服务部署方案具有直接参考价值。

1. 基于 K8S 容器云平台的微服务部署方案：先看清它能解决什么

做容器云的人迟早会撞上同一个问题：单体应用微服务化以后，几十个服务之间有依赖、有先后、有各自的副本数，手工启动根本管不过来，这时候 K8S 的编排能力就成了刚需。这份资料是社区专家从企业落地经验里整理出来的，围绕 K8S 和 Openshift 讲了部署框架怎么搭、多租户怎么隔离、日志监控怎么接、微服务怎么拆，覆盖了从集群建设到应用发布的全链路。它不是那种只讲概念的教程，里面全是带着网络拓扑、参数配置和权限模型的实践答案，适合正在做容器云平台选型、或者已经上了 K8S 但被服务发布和多租户隔离困扰的架构师和运维工程师。

2. 部署框架与多租户隔离：双环境架构与 OVS 网络选型

2.1 两套 Openshift 环境：为什么 DMZ 和内网必须物理隔离

资料里第一个落地的决策就是网络边界问题：在 DMZ 和内网分别部署彼此独立的 2 套 Openshift，两套环境彼此隔离。这个动作不是管理员强迫症，而是企业安全策略决定的——DMZ 区跑对外发布的应用，直接面对外网流量，内网区跑内部应用，访问数据库等核心资源。两套环境如果共用一套集群，一旦 DMZ 区某个应用被攻破，内网应用就全部暴露了。

我一般会建议在规划阶段就把环境隔离当成硬性需求，而不是等安全审计来提。两套 Openshift 隔离的不只是网络，还有镜像仓库和权限体系。资料里提到外部镜像仓库独立于 OCP 平台之外，QA 环境 CD 推送到生产环境的镜像先复制到外部镜像仓库，再由平台导入内部镜像仓库，这个流程保证了 DMZ 和内网两个环境拿到的镜像是同一份，但运行环境完全隔离。

# 安装 Openshift 时指定多租户 SDN 插件（典型的高级安装配置片段） os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'

注意这个参数，它决定了整个集群的租户隔离能力。默认的 ovs-subnet 插件实现的是类似 flat 网络的模型，所有 Pod 之间互通，适合开发测试环境。生产环境如果要做到 project 级别网络隔离，必须换成 ovs-multitenant。这个选择直接影响后续多租户体系能不能撑起来，我见过不少团队前期图省事用默认插件，后面租户一多，网络隔离推倒重来。

2.2 Project 与租户隔离：四层机制缺一不可

Openshift 里的 Project 概念来源于 K8S 的 namespace，但功能上做了扩展。租户隔离不是靠单一机制完成的，而是四层叠加：权限控制、网络隔离、Router 隔离、物理资源池隔离。权限控制通过细粒度权限管理，给不同用户和组设置不同 project 的权限；网络隔离用 OVS 给每个 project 分配 VNID，不同 VNID 流量自动隔离；Router 隔离让不同 project 用独立 Router，避免流量互相干扰；物理资源池隔离则靠 nodeSelector 把特定计算节点划给指定 project 独享。

# nodeSelector 示例：将应用固定调度到带指定标签的计算节点 apiVersion: apps/v1 kind: Deployment metadata: name: payment-service namespace: payment-prod spec: replicas: 2 selector: matchLabels: app: payment template: metadata: labels: app: payment spec: nodeSelector: zone: dmz-payment # 节点标签，部署前先给计算节点打上 containers: - name: payment image: registry.internal/payment:1.4.2 ports: - containerPort: 8080

这段 YAML 里 nodeSelector 是关键：它让支付服务只调度到带zone: dmz-payment标签的节点上。结合资料里的实施建议，应用迁移到容器云时资源申请按现有配置设置，横向扩展也只在已分配的计算节点上进行，如果资源不足再申请新节点。这样做的好处是物理资源可预期，但也容易造成节点资源浪费，建议标签粒度不要太细，按可用区或业务域划分，而不是按单个应用划分。

2.3 网络插件选型：ovs-multitenant、flannel+hostgw 和 calico 怎么选

Openshift 完全支持 CNI 标准，所以三方 SDN 插件都能用，目前支持的有 Cisco Contiv、Juniper Contrail、Nokia Nuage、Tigera Calico、VMware NSX-T。但选型不能只看功能列表，要看你的基础设施现状。如果你的 K8S 跑在已有云平台的虚机上，比如 OpenStack，那么使用 OVS 插件可能出现 overlay on overlay 的情况——IaaS 底层已经有一层 overlay 网络，容器再套一层，网络性能会明显下降。这种情况下 flannel+hostgw 是个务实选择，它用主机路由的方式避免二次封装，性能比 ovs-multitenant 好，代价是牺牲了多租户网络隔离能力。

还有一个常见误区：以为多租户隔离只能靠网络插件。实际上租户隔离是分层的，如果只需要权限隔离，RBAC 就够了；如果要求网络层不通，才需要换多租户插件。我一般建议从简单方案开始，业务上确实出现跨租户访问需求时再升级网络插件，但要注意升级网络插件会重建整个集群的网络层，是高风险操作，测试环境多跑几个星期再说。

2.4 已有云平台的利旧：性能和架构的取舍

很多客户在上容器平台之前已经有了私有云平台，纠结是买物理机另起炉灶还是基于已有云平台部署。这个问题本质上是性能焦虑，大部分企业物理机资源常年处于低负荷状态，以性能为借口直接上物理机并不理性。如果决定跑在已有云平台上，要重点解决三个问题：一是充分利用 IaC 实现自动化编排部署，比如 OpenStack 里的 heat，这是裸机集群最缺的能力；二是网络性能，前面提到尽量防止二次封装叠加；三是架构上要有向后扩展性，比如后期可能要引入 Service Mesh，前期就要考虑兼容性。

3. 认证与权限体系：双向认证、Token 与 SCC 细粒度控制

3.1 三种认证方式的适用边界

Kubernetes 系统提供 CA 认证、Token 认证和 HTTP Base 认证三种方式。很多刚接触 K8S 的人以为认证方式越严格越好，但资料里给了个反直觉的建议：集群内各组件访问 API Server 时，由于与 API Server 同处一个局域网，建议用非安全方式访问，效率更高。安全功能是一把双刃剑，保护系统不被攻击的同时也带来额外性能损耗，内网组件之间走性能优先，外部访问走安全优先，这个边界要分清。

Openshift 在这个基础之上做了工程化封装，平台内置了基于 OAuth 的通用身份认证服务器，所有操作都基于 API，用户可以是开发人员或管理员，通过多种认证源完成认证。这意味着企业内部的 LDAP、AD 等认证体系可以直接对接，不用每个系统各搞一套账号密码。

3.2 CA 双向认证的配置流程

双向认证是集群安全最严格的配置方式，核心流程三步走：生成根证书、API Server 服务端证书及私钥、各组件客户端证书及私钥，然后修改各个服务进程启动参数启用双向认证。我在实际配置中习惯用脚本一次性生成整套证书，避免手动操作漏掉某个组件。

# 生成 CA 根证书、服务端证书和客户端证书的关键步骤 # 1. 创建 CA 根证书私钥 openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=kube-ca" -days 3650 -out ca.crt # 2. 生成 API Server 服务端证书 openssl genrsa -out apiserver.key 2048 openssl req -new -key apiserver.key -subj "/CN=kube-apiserver" -out apiserver.csr openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out apiserver.crt # 3. 修改 kube-apiserver 启动参数启用双向认证 # --client-ca-file=/etc/kubernetes/pki/ca.crt # --tls-cert-file=/etc/kubernetes/pki/apiserver.crt # --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

这里的参数说明要强调：--client-ca-file指定的是验证客户端证书的 CA 文件，--tls-cert-file和--tls-private-key-file是 API Server 自己的证书和私钥。启用双向认证后，所有请求必须携带合法客户端证书，否则直接拒绝。还要注意证书有效期，我曾见过因为证书没配自动轮换，集群某天突然全部认证失败，kubelet 全部报 Unauthorized，排查了半天才发现是 CA 证书过期。K8S 1.20 之后可以用kubeadm cert renew统一管理，但如果是手工生成的证书，建议在日历上设个证书过期提醒。

3.3 SCC：比 RBAC 更细一层的 Pod 权限控制

除了认证和鉴权，Openshift 还提供了面向 Pod 的细粒度权限控制 SCC（Security Context Constraints），用来限制 Pod 具备何种类型的权限：容器是否可以运行在特权模式下、是否可以挂载宿主机目录、是否可以使用宿主机端口、是否可以以 root 用户运行等等。这个机制解决的是运行时安全问题，RBAC 管的是谁能操作什么资源，SCC 管的是 Pod 跑起来后能碰宿主的什么能力。

我见过一个典型的翻车案例：团队在 Openshift 上部署一个有状态应用，容器启动时进程要绑定宿主机的某个端口，集群默认的 SCC 禁止了这个操作，应用 Pod 一直 CrashLoopBackOff，报错信息是 permission denied。排查了一圈发现不是镜像问题，是 SCC 配置不允许 Pod 使用宿主机端口。解决方式是给该服务单独创建一个 SCC 策略，或者调整部署方式，通过 NodePort Service 暴露端口而不是让容器直接绑宿主端口。SCC 的配置原则是尽量用约束性强的默认策略，特殊需求再单独开，不要图省事把整个 namespace 都放开。 ## 4. 服务发布与负载均衡：从 ClusterIP 到 NodePort 与 Router ### 4.1 Service 三层抽象与服务发现 K8S 里的 Service 是微服务架构的核心抽象，每个 Service 关联一系列 Pod，通过 Label Selector 筛选 Pod，用 Endpoint 衔接。Service 被分配一个虚拟 IP 即 ClusterIP，它由 K8S 虚拟出来，外部寻址不到，范围通过 API Server 启动参数 `--service-cluster-ip-range=19.254.0.0/16` 配置，由 kube-proxy 负责虚拟 IP 路由和转发。这套机制解决的问题是：Pod 的 IP 是动态的，随意关停重启，只要有 Service 在外面挡着，服务访问不受影响。 Service 的好处还在于可以代理集群外部的服务。比如要代理外部 MySQL，创建 Service 时不设置 Label Selector，手动定义 Endpoint 指向 MySQL 的 IP，组件访问 Service 就等于访问外部数据库，数据库迁移时只需改 Endpoint，不用改应用配置。 ### 4.2 对外发布：NodePort、LoadBalancer 与 Ingress 微服务化应用的每个组件都以 Service 进行抽象，组件之间只访问 Service 就能互相通信。但外部访问集群内服务是另一套逻辑，K8S 提供三种发布方式：NodePort Service、LoadBalancer Service 和 Ingress。 ```yaml # NodePort 类型 Service 示例 apiVersion: v1 kind: Service metadata: name: payment-svc namespace: payment-prod spec: type: NodePort selector: app: payment ports: - port: 8080 # Service 对外提供服务的端口 targetPort: 8080 # 容器内部应用监听的端口 nodePort: 30080 # 每个 Node 上暴露的端口，范围 30000-32767

NodePort Service 会在集群所有节点上监听同一个特定端口，访问任意节点 IP 加端口即可访问内部容器服务。这里有个容易被忽略的点：nodePort 端口范围默认是 30000-32767，如果指定的端口不在范围内，创建会报错。还有一点就是 NodePort 会在所有节点上占用该端口，集群规模大了以后端口管理会混乱，这时候就需要 Ingress 来收敛。

Ingress 充当入口网关的角色，根据域名和路径把请求路由到不同的 Service。比如payment.example.com路由到 payment-svc，order.example.com路由到 order-svc，避免了每个 Service 都占用一个 NodePort。LoadBalancer Service 则依赖底层云平台创建负载均衡器，把每个 Node 作为后端，云平台 LB 转发请求到 NodeIP 加 NodePort，这在裸机环境或私有云里没法直接用，需要环境支持。

4.3 F5 与 Router 组合的动态负载均衡

生产环境的负载均衡从来不是 K8S 一个组件能搞定的。资料里提到的方案是双轨制：NodePort Service 结合 F5 和 Keepalived 做外部访问入口，F5 VS 的 Pool Member 配置所有节点，Keepalived 实现节点高可用；平台内部用 Router 做应用流量负载均衡，Router 基于软件即 HAProxy 实现，容服务弹性伸缩时无需人工对负载均衡设备进行配置干预。

这里最值得学习的是 Router 的动态负载均衡机制：平台内部通过软件定义网络为每个应用容器分配了内网 IP，外部客户无法直接访问，Router 负责转发外部流量到具体应用容器。Router 会动态检测平台的元数据仓库，当有新的应用部署或应用实例发生变化时，自动根据变化更新路由信息。这意味着你不需要在 LB 设备上手工增删后端，K8S 的弹性伸缩和 Router 的路由更新是自动联动的。

用 NodePort 发布服务还有一种优化方式：资料里说 Openshift 推荐通过 NodePort 类型的 Service 对外暴露服务端口，然后在 F5 VS 的 Pool Member 中配置所有计算节点，通过 Keepalived 实现 HA。这个组合解决了高可用问题，但要注意 F5 的健康检查必须针对 NodePort 端口，而不是应用直接暴露的端口，否则后端状态会误判。

4.4 服务访问与防火墙的配合

内网计算节点可以直接访问数据库，DMZ 区计算节点访问数据库有两种方案：一种是计算节点直接通过内网防火墙访问应用数据库，防火墙仅开通应用所在节点访问数据库的端口；另一种是计算节点经 Outbound 路由通过内网防火墙访问内网数据库，这个 Outbound 路由在 Openshift 中叫 Egress Router。第一种方案网络路径短、性能好，但每扩展一个节点就要在防火墙上加一条规则；第二种方案把出口收敛到固定节点，防火墙规则稳定，但流量会多一跳。我一般建议按安全合规要求来选，金融行业通常选 Egress Router，因为审计要求防火墙规则可控可枚举。

5. 日志、监控与高可用：EFK 落地的五条避坑记录

5.1 日志链路：EFK 为什么能接住容器日志

容器日志和传统应用日志有本质区别，传统应用通过 log4j 等机制把日志写到文件里方便查看排错，但容器是随建随销的，Pod 一重建本地文件就没了，所以日志必须持久化到外置存储。资料里给出的做法是把日志按 namespace 建立目录，保存在计算节点挂载的 NFS 存储上。

分布式环境下日志分散，解决办法是集中收集、结构化处理、再按角色分发。OpenShift 用 EFK 实现日志管理平台，EFK 是 Elasticsearch、Fluentd、Kibana 的简称：Fluentd 负责数据采集、过滤、传输，性能强、功能全，尤其在容器日志收集领域基本是标准方案；ES 负责数据的存储和索引；Kibana 负责数据展示。日志按角色分发是关键能力，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志，一套日志平台必须支持按不同视角过滤查询。

# EFK 部署完成后，检查日志链路是否正常的常用命令 # 1. 查看 Fluentd 采集端是否正常 oc get pods -n logging -l component=fluentd # 2. 查看 ES 索引是否在增长（索引名通常按日期滚动） curl -s http://es-cluster:9200/_cat/indices?v | grep logstash # 3. 查看 Kibana 是否能查到数据 oc logs -n logging kibana-xxx | grep "error"

这里要提醒的是，ES 的后端存储不建议用分布式存储。日志量大时，分布式存储的写入会成为瓶颈，这是资料原文的明确观点。实际测试中，ES 集群对存储的随机写入和 IOPS 要求很高，分布式存储的强一致机制会拖慢写入性能，建议用本地存储或者集中存储。集中存储目前用得最多，FCSAN 或 IPSAN 的稳定性和安全性都够用，风险在性价比和扩展性上，要预留好容量增长空间。

5.2 监控选型：从 heapster 到 prometheus 的切换逻辑

K8S 集群监控方案经历过三个阶段：heapster 加 influxDB、heapster 加 hawkular、prometheus。早期的 heapster 方案负责监控数据的采集和汇总，搭配 influxDB 存储或 hawkular 展示；当前的主流方案是 prometheus。为什么 prometheus 胜出？因为 cAdvisor 支持 prometheus，包含了 cAdvisor 的 kubelet 也支持 prometheus，每个节点都提供了供 prometheus 调用的 API。prometheus 调用 Master 的 API Server 获取节点信息，然后去调取每个节点的数据，作为时间序列数据库天然适配监控场景。Openshift 3.12 版本里 heapster 被 prometheus 替换，社区判断已经很清楚。

监控的覆盖面要分两层：主机监控和容器监控。nodeExporter 收集主机监控信息，cAdvisor 收集容器监控信息。这里有个参数要特别注意，kubelet 需要配置 kube-reserved 和 system-reserved 参数给系统预留内存，不然后台节点内存被容器吃光时，kubelet 本身会先挂，集群直接宕机。这个参数我建议配置了 K8S 1.8 以上版本就开始预留，不要等到生产中节点反复出现 NotReady 才去补。

5.3 高可用设计：镜像仓库、Master、计算节点三条线

高可用不是单一层面的问题，至少要分三条线：外部镜像仓库高可用、Master 主控节点高可用、计算节点及容器应用高可用。外部镜像仓库独立于 OCP 平台，使用 2 台服务器加 F5 负载均衡，后端镜像仓库挂载 NFS 共享存储。Master 主控节点承担集群管理职责，Master 挂掉整个集群就失去控制面。计算节点高可用靠的是容器应用的高可用，一个计算节点异常停机后，其上的容器会逐步迁移到其他节点，同时通过标签管理节点，部署时用 nodeSelector 指定目标节点，目标节点数大于 1 才能避免单点故障。

这里有个细节容易被忽略：外部镜像仓库为什么要跟平台内部镜像仓库分开？因为外部无法直接访问 OCP 平台内部镜像仓库，所以 QA 环境 CD 推送到生产环境的镜像先复制到外部镜像仓库，再由平台导入内部镜像仓库。这个流程保证了镜像的唯一来源，也避免了外部直接操作生产集群的镜像仓库。

5.4 高频踩坑记录

坑一：ES 写入性能差，日志积压严重。现象是 Fluentd 报错 OOM，Kibana 查询数据延迟十几分钟。原因是把 ES 后端存储放到了分布式存储上，高并发写入触发分布式存储的复制同步开销，写入成为瓶颈。解决方式是改用本地存储或集中存储，给 ES 节点单独挂 SSD，同时调整 Fluentd 的 buffer 参数降低单批写入量。

坑二：容器日志不持久化，Pod 一重启日志全丢。现象是排障时想查容器之前的输出信息，结果kubectl logs只能看到当前实例的日志。原因是应用日志没做持久化挂载，Log4j 机制写本地文件随容器销毁。解决方式是把日志目录挂载到 NFS 存储，按 namespace 建立目录划分，同时应用侧统一使用日志采集 agent 收集。

坑三：容器网络叠加导致性能下降明显。现象是容器服务吞吐量比虚机上直接部署低 30% 以上。原因是 IaaS 层已有 overlay 网络，容器网络再套一层，二次封装开销叠加。解决方式是宿主机网络选 flannel+hostgw，或直接走 calico BGP 模式，尽量让容器流量走主机路由表而非隧道封装。

坑四：dubbo 服务注册到 zookeeper 后消费方连不上。现象是 K8S 上的 provider 在 zk 里注册的是容器地址，K8S 外部的 consumer 拿到这个地址后没法访问。原因是容器 IP 是集群虚拟网络的地址，外部网络路由不到。解决方式是外部消费方通过 NodePort 或 Ingress 访问，provider 端注册时配置外网可达的地址，或者让消费方也迁移到 K8S 集群内走 Service 发现。

坑五：nodeSelector 只匹配一个节点，宕机后服务调度不出去。现象是某计算节点宕机后，应用 Pod 一直 Pending。原因是部署时 nodeSelector 指定的标签只有那一个节点有，调度器找不到满足条件的其他节点。解决方式是按可用区或节点池打标签，保证标签组合匹配的节点数大于 1，同时用 PodDisruptionBudget 限制同时不可用的副本数。

6. 微服务拆分与 CI/CD：从 Kolla 参考到最小验证链路

拆分粒度是微服务架构里最容易扯皮的问题，没有标准答案，但有一个非常值得参考的实践：OpenStack 的 Kolla 项目，它把 OpenStack 这么大规模的开源项目拆成了微服务跑在容器里。拆分的思路分两步：先按服务功能划分粗粒度模块，比如计算服务、网络服务、存储服务，粗粒度模块共享同一个 base 镜像，预置共性依赖；再按服务的原子性拆分，把 Nova 拆成 nova-api、nova-scheduler、nova-compoute、nova-libvirt，拆分到不能再拆为止，原子拆分的产物是彼此独立的单进程，也就是叶子节点，每个叶子节点用自己的独立镜像。镜像继承关系是centos-base -> centos-openstack-base -> centos-nova-base -> centos-nova-api，这种分层设计让镜像构建有清晰的依赖链，公共依赖只构建一次。

CI/CD 的问题和 SVN 还是 Git 无关，关键是 pipeline 怎么构建。SVN 环境下用 hook 实现 post commit 触发灵活度存在，也仅在 repo 粒度较细时可行，大的 repo 管理复杂。我一般建议用 Jenkins 轮询 SCM 的方式触发 pipeline，链路是gitlab/svn -> Jenkins -> build images -> push images -> docker-registry -> pull images -> containers。整条链路的验证重点不在最前端的代码仓库，而在镜像构建和发布环节。构建阶段要保证镜像标签和代码提交一一对应，发布阶段要保证 K8S 拉取的镜像是刚构建出来的那个版本。

# 最小 CI/CD 验证链路（Jenkins pipeline 片段） # 1. 轮询 SCM 检测代码变更（SVN 场景下用 pollSCM 代替 hook） pipeline { triggers { pollSCM('H/5 * * * *') } stages { stage('Build Image') { steps { sh 'docker build -t registry.internal/${APP_NAME}:${BUILD_NUMBER} .' sh 'docker push registry.internal/${APP_NAME}:${BUILD_NUMBER}' } } stage('Deploy to K8S') { steps { sh 'kubectl set image deployment/${APP_NAME} ${APP_NAME}=registry.internal/${APP_NAME}:${BUILD_NUMBER} -n ${NAMESPACE}' sh 'kubectl rollout status deployment/${APP_NAME} -n ${NAMESPACE}' } } } }

关于微服务框架选型，Service Mesh 和 Spring Cloud 的争议这几年一直在。Spring Cloud 是侵入式框架，代码里要引入大量微服务组件依赖；Service Mesh 是非侵入式的，以 sidecar 代理的方式和应用代码并行部署，应用不需要感知。2018 年以前扛起微服务大旗的可能是 Spring Cloud，但现在 Service Mesh 在流量管理和可观测性上的优势越来越明显。我的判断是：如果系统已经深度绑定 Spring Cloud，不用急着迁移；如果是新项目，直接考虑 Service Mesh，Istio 或 Linkerd 都行，把流量管理从业务代码里剥出去，长期看维护成本低很多。

还有个容易被忽略的坑：K8S 目前缺少可视化的服务编排组件，满世界的 YAML 让人眼花缭乱。单纯用 K8S 很难构建一套平台出来，要构建自动化编排平台，应该以 K8S 为内核，集成外围生态软件，这也正是 Openshift 存在的意义。可视化编排组件这个需求，可以按应用类型指定 YAML 模板，前端页面调用 K8S API 动态更新资源描述并使其生效，拖拽功能在前端设计，后端对应需要调哪些 API，工作量不小。从那以后我做微服务生产发布，都强制先跑一遍kubectl get events和kubectl describe pod，再决定要不要动负载均衡策略，省的每次都被 Pod 拉起失败打脸，希望帮到你。

本文还有配套的精品资源，点击获取