简介基于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_nameredhat/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、flannelhostgw 和 calico 怎么选Openshift 完全支持 CNI 标准所以三方 SDN 插件都能用目前支持的有 Cisco Contiv、Juniper Contrail、Nokia Nuage、Tigera Calico、VMware NSX-T。但选型不能只看功能列表要看你的基础设施现状。如果你的 K8S 跑在已有云平台的虚机上比如 OpenStack那么使用 OVS 插件可能出现 overlay on overlay 的情况——IaaS 底层已经有一层 overlay 网络容器再套一层网络性能会明显下降。这种情况下 flannelhostgw 是个务实选择它用主机路由的方式避免二次封装性能比 ovs-multitenant 好代价是牺牲了多租户网络隔离能力。插件网络模式多租户隔离性能适用场景ovs-subnetflat 网络不支持中等开发测试环境ovs-multitenantVNID 隔离支持中等企业生产多租户flannelhostgw主机路由不支持较好已有 IaaS 云平台叠加部署calicoBGP 路由支持网络策略好大规模集群、需要 NetworkPolicy 的场景还有一个常见误区以为多租户隔离只能靠网络插件。实际上租户隔离是分层的如果只需要权限隔离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 /CNkube-ca -days 3650 -out ca.crt # 2. 生成 API Server 服务端证书 openssl genrsa -out apiserver.key 2048 openssl req -new -key apiserver.key -subj /CNkube-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 的细粒度权限控制 SCCSecurity 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-range19.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-32767NodePort Service 会在集群所有节点上监听同一个特定端口访问任意节点 IP 加端口即可访问内部容器服务。这里有个容易被忽略的点nodePort 端口范围默认是 30000-32767如果指定的端口不在范围内创建会报错。还有一点就是 NodePort 会在所有节点上占用该端口集群规模大了以后端口管理会混乱这时候就需要 Ingress 来收敛。Ingress 充当入口网关的角色根据域名和路径把请求路由到不同的 Service。比如payment.example.com路由到 payment-svcorder.example.com路由到 order-svc避免了每个 Service 都占用一个 NodePort。LoadBalancer Service 则依赖底层云平台创建负载均衡器把每个 Node 作为后端云平台 LB 转发请求到 NodeIP 加 NodePort这在裸机环境或私有云里没法直接用需要环境支持。Service 类型ClusterIP外部访问方式适用场景ClusterIP有仅集群内部服务间调用NodePort有[NodeIP]:[NodePort]小规模外部访问LoadBalancer有云平台 LB公有云环境Ingress间接域名/路径路由多服务统一入口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 componentfluentd # 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 报错 OOMKibana 查询数据延迟十几分钟。原因是把 ES 后端存储放到了分布式存储上高并发写入触发分布式存储的复制同步开销写入成为瓶颈。解决方式是改用本地存储或集中存储给 ES 节点单独挂 SSD同时调整 Fluentd 的 buffer 参数降低单批写入量。坑二容器日志不持久化Pod 一重启日志全丢。现象是排障时想查容器之前的输出信息结果kubectl logs只能看到当前实例的日志。原因是应用日志没做持久化挂载Log4j 机制写本地文件随容器销毁。解决方式是把日志目录挂载到 NFS 存储按 namespace 建立目录划分同时应用侧统一使用日志采集 agent 收集。坑三容器网络叠加导致性能下降明显。现象是容器服务吞吐量比虚机上直接部署低 30% 以上。原因是 IaaS 层已有 overlay 网络容器网络再套一层二次封装开销叠加。解决方式是宿主机网络选 flannelhostgw或直接走 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 MeshIstio 或 Linkerd 都行把流量管理从业务代码里剥出去长期看维护成本低很多。还有个容易被忽略的坑K8S 目前缺少可视化的服务编排组件满世界的 YAML 让人眼花缭乱。单纯用 K8S 很难构建一套平台出来要构建自动化编排平台应该以 K8S 为内核集成外围生态软件这也正是 Openshift 存在的意义。可视化编排组件这个需求可以按应用类型指定 YAML 模板前端页面调用 K8S API 动态更新资源描述并使其生效拖拽功能在前端设计后端对应需要调哪些 API工作量不小。从那以后我做微服务生产发布都强制先跑一遍kubectl get events和kubectl describe pod再决定要不要动负载均衡策略省的每次都被 Pod 拉起失败打脸希望帮到你。本文还有配套的精品资源点击获取