自己做K8s实操到一定阶段基本都会卡在同一个坎上基础命令都熟了单独部署一个nginx或者tomcat也没问题但真要把一整套业务系统搬上集群就不知道从哪里下手。这期要聊的是一套我在实际项目中反复验证过的组合——zookeeper、nginxtomcat、redis、mysql、java应用、LNMP、dubbo微服务外加一个ingress统一入口。这一条线基本覆盖了从Web站点到分布式中间件再到微服务治理的完整链路。如果你正在学K8s或者准备把现有业务做容器化迁移这篇可以直接拿来当参考清单用。我分五块来讲先拆整体设计思路和工作负载选型再逐个看有状态组件和无状态应用怎么落地然后说dubbo和ingress这两个偏架构的环节最后把常见的坑和排查路径汇总成一张速查表。每个部分都会带上可复制的配置思路和参数选择过程不搞那种“配置随便写写”的应付式内容。1. 先想明白一件事这些组件放在一起到底组成了什么1.1 一条业务链路把八个关键词串起来很多人看到这一长串组件名就头大其实它们不是八座孤岛。我习惯把整条链路分成四层第一层是入口层也就是ingress。用户请求从ingress进来按域名或路径规则转发到后面的Service。这个位置以前是nginx或者F5干的活现在在K8s里变成了一个独立的调度节点。第二层是接入层nginxtomcat也好纯LNMP也好本质都是Web容器。nginx负责静态资源、反向代理、负载均衡tomcat或PHP-FPM处理动态逻辑。接入层后端就是业务应用。第三层是业务层这里分两条路线一条是传统Java应用加上Redis做缓存、MySQL做持久化另一条是dubbo微服务几个Provider加一个Consumer靠zookeeper做注册中心。第四层是数据层mysql存业务数据redis扛热点数据zookeeper存注册元数据。这一层是有状态组件的集中地也是K8s化改造中最容易翻车的地方。你把这四层串起来再看标题里的八个关键词就从“一堆名词”变成了“一张架构图”。做容器化迁移最忌讳的就是一个个组件单独搞搞完发现服务之间根本连不通。先有链路意识再去动手能省掉大量返工时间。1.2 工作负载类型怎么选Deployment不是万能解K8s里最常见的工作负载类型有Deployment、StatefulSet、DaemonSet很多人部署什么都套Deployment这是一个非常典型的新手习惯。选错工作负载类型最直接的表现就是应用能用但一重启就出问题比如zookeeper集群起不来、mysql数据丢、dubbo服务重复注册。我给出一个非常粗糙但足够实用的选型准则判断维度用Deployment用StatefulSet状态特性无状态重启换IP无所谓有状态需要稳定网络标识数据持久化丢数据可接受丢数据等于事故必须挂PVC扩缩容方式随便加减副本按序号创建/删除顺序有讲究典型组件Java应用、Nginx、PHP-FPMZookeeper、Redis、MySQL集群发现方式靠Service做负载池靠Headless Service拿到每个Pod的固定DNSLNMP里的Nginx和PHP-FPM、Java应用、dubbo的Provider和Consumer全部用Deployment因为它们可以随时重启、迁移IP变了不影响业务。zookeeper、redis、mysql这三类就必须上StatefulSet因为它们要么需要固定身份要么数据不能丢要么客户端要持久连接。除了这两类DaemonSet在日志采集、监控Agent场景下才会用到本文涉及的业务组件基本碰不上但排查Pod异常时看到这个名字要认识。1.3 镜像和配置管理的几个基础规范实操之前先立几条规矩这些都是后来反复踩坑总结出来的镜像Tag不要用latest。我见过不止一次镜像仓库里latest被新版本覆盖集群里刚好有节点没有本地缓存一拉全换成了新版本依赖老版本的业务直接崩。固定版本号升级由你说了算不要让拉取时机决定版本。配置文件和敏感信息要分离。环境变量级别的配置放ConfigMap密码、密钥放Secret都不要写进镜像。这是K8s化的一个核心思路镜像不变配置变环境A切环境B就改一下配置对象镜像不用重新构建。这种模式对多环境发布特别友好。镜像拉取策略按场景设置。部署到生产集群时如果镜像已经在节点上有缓存可以设置ImagePullPolicy为IfNotPresent减少对镜像仓库的依赖。但调试阶段建议Always避免本地缓存干扰验证结果。同一套配置在不同场景下灵活调整比机械执行标准答案重要。2. 有状态组件部署Zookeeper、Redis、MySQL在K8s里的正确姿势2.1 Zookeeper无头Service是集群通信的基础Zookeeper在K8s里跑最常见的部署方式是三节点集群配套一个无头ServiceClusterIP为None。为什么要无头Service很多人没想明白。普通Service给所有后端Pod提供一个统一的虚拟IP客户端访问时随机转发到其中某一个。对于zookeeper这种客户端需要跟每个节点都建立长连接的组件虚拟IP一隐藏节点身份集群通信就乱了。Headless Service做的事情是不创建虚拟IP而是给每个Pod生成一个稳定的DNS记录。比如StatefulSet叫zkService叫zk-hs命名空间middleware那么zk-0这台Pod的DNS就是zk-0.zk-hs.middleware.svc.cluster.localzk-1、zk-2依此类推。这个固定域名就是zookeeper节点间互相访问的身份凭证。一个可以直接参考的部署配置大概是这样的apiVersion: v1 kind: Service metadata: name: zk-hs namespace: middleware spec: clusterIP: None selector: app: zookeeper ports: - port: 2181 name: client --- apiVersion: apps/v1 kind: StatefulSet metadata: name: zk namespace: middleware spec: serviceName: zk-hs replicas: 3 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: bitnami/zookeeper:3.8 env: - name: ZOO_SERVERS value: - zk-0.zk-hs.middleware.svc.cluster.local:2888:3888; zk-1.zk-hs.middleware.svc.cluster.local:2888:3888; zk-2.zk-hs.middleware.svc.cluster.local:2888:3888 - name: ALLOW_ANONYMOUS_LOGIN value: yes ports: - containerPort: 2181 name: client volumeMounts: - name: data mountPath: /bitnami/zookeeper volumeClaimTemplates: - metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi这里有个细节要特别注意zs_SERVERS环境变量里节点的地址必须用完整FQDN不要偷懒只写主机名。虽然K8s的DNS搜索域在某些情况下能自动补全但跨命名空间、跨集群场景下很容易出解析问题写全最保险。端口2181是客户端端口2888是节点间数据同步端口3888是选举端口。三个端口配不对集群表面起来了实际通信一塌糊涂。Zookeeper的VolumeClaimTemplates也很关键。StatefulSet每个副本都会按模板申请一块独立的PVCzk-0、zk-1、zk-2各自拥有自己的数据盘互不干扰。这里不能用多个Pod共用一个ReadWriteMany存储来存zookeeper数据会产生数据文件锁冲突这是很多人低调踩过的坑。2.2 Redis缓存选型要区分单点、哨兵和集群Redis在K8s里的部署方式需要先看用途。只做纯缓存数据丢了可以重建用Deployment加一个普通Service就能跑甚至不需要持久化。但如果你拿Redis当存储用比如存了用户会话、计数、排行榜这些丢不起的数据就必须开AOF持久化并且把数据目录挂到PVC上。单点Redis加持久化的配置思路是镜像用redis:7.0启动参数指向自定义的redis.conf开启appendonly。配置通过ConfigMap挂载进去数据目录/data用StatefulSet的volumeClaimTemplates来挂。举个例子redis.conf里至少要包含appendonly yes appendfsync everysec maxmemory 1gb maxmemory-policy allkeys-lrumaxmemory和K8s内存Limit的关系值得单独说。Pod的resources.limits.memory设置的是容器能用的物理内存上限Redis的maxmemory是Redis内部管理的缓存上限。如果Limit是2Gimaxmemory设置到1.5Gi左右剩下的留给Redis自身缓冲和开销。maxmemory设太高内存被占满触发OOMKilled容器被Kubelet杀掉重启设太低热数据根本没缓存住数据库压力白扛。这个比例关系我在生产环境里一般给到70%左右具体看业务特性。如果你要部署Redis哨兵模式或者Redis Cluster配置复杂度会高一个量级。哨兵模式本质上是三个Redis加三个Sentinel靠服务发现和故障自动切换每个节点都要独立的配置文件和互不重复的节点名。Cluster模式则要求至少6个节点3主3从而且要开端口16379作为集群总线通信。这类部署推荐直接用能感知StatefulSet的官方或社区Operator手动硬配不是不行但维护成本极高。2.3 MySQL存储、初始化和参数一个都不能少MySQL在K8s里的部署我的建议非常直接单实例上StatefulSet不用Deployment。原因就一条数据文件必须落本地持久卷。数据库容器一旦被调度到新的节点如果数据不在同一个节点或者没有共享存储整个库就没了。一个基础配置示例apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql namespace: middleware spec: serviceName: mysql-svc replicas: 1 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:8.0 envFrom: - secretRef: name: mysql-secret volumeMounts: - name: data mountPath: /var/lib/mysql - name: init mountPath: /docker-entrypoint-initdb.d volumes: - name: init configMap: name: mysql-init volumeClaimTemplates: - metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 50GiMySQL容器有一个非常有用的机制/docker-entrypoint-initdb.d目录下的脚本在数据目录为空时会被自动执行数据目录已有内容则跳过。这个机制解决了一个很实际的问题——初始化建库建表SQL不用再人肉去执行。做法是把这个目录挂成ConfigMap把建库SQL放进去。注意这个目录适合放结构定义和基础数据不适合放几十GB的业务数据它本质上是初始化不是迁移。密码相关的配置必须走Secret不要放在ConfigMap里明文躺平。mysql-secret中至少包含MYSQL_ROOT_PASSWORD、MYSQL_DATABASE、MYSQL_USER、MYSQL_PASSWORD这几个键。Secret在Pod里通过envFrom注入成环境变量MySQL官方镜像首次启动时会读取这些变量完成root密码设置和初始库创建。存储和参数这两块生产项目通常还需要考虑数据盘大小按日志增长速度估量不要一开始给个小盘后面还得费劲迁移。字符集在初始化时就定成utf8mb4后面再改非常麻烦。MySQL实例本身的性能参数比如innodb_buffer_pool_size可以参考K8s内存Limit的50%到70%设置设太大容易和缓存层互相挤占内存。3. 无状态应用编排Java、NginxTomcat、LNMP怎么凑齐一整条Web线3.1 Java应用部署配置外置和JVM参数是重中之重Java应用在K8s里部署最核心的一件事是把JVM内存参数和容器资源限制对应起来。用JDK版本太老的人经常碰到这种情况容器Limit设了2GiJVM没感知到容器限制自己按宿主机内存大小算了堆内存一压测就OOM容器被频繁重启。有两种解法。一种是用JDK 8u191以上的版本JVM默认开启UseContainerSupport能识别容器内存限制配合-XX:MaxRAMPercentage75.0这样的比例参数让堆内存跟随容器Limit动态调整。另一种是手动把-Xmx、-Xms写死成具体值比如容器Limit 2GiXmx设成1.5g。两种都行我推荐第一种后面调容器大小的时候不用改配置。构建镜像的方面标准做法是多阶段构建。用Maven镜像编译打包出jar再用一个精简运行时镜像启动最终镜像只包含JRE和jar包大小比把整个构建环境带进去小一个数量级。对于高并发业务启动命令记得加Djava.security.egdfile:/dev/urandomJava的SecureRandom初始化在某些系统上会阻塞很长时间加上这个能显著缩短启动时间。探针对Java应用格外重要。K8s的livenessProbe和readinessProbe是两回事readiness就绪探针控制流量是否进入Podliveness存活探针决定Pod要不要重启。Java应用启动慢探针参数设置不合理经常会陷入“还没就绪就被干掉重启”的循环。一般规律是initialDelaySeconds给到30到60秒periodSeconds给到10秒左右探针路径直接指向应用的健康检查接口。没有现成健康接口的至少想办法加一个不要用TCP端口代替一切TCP通不代表应用真的能处理请求。3.2 NginxTomcat的双容器组合动静分离的两种跑法NginxTomcat这套组合在K8s里有两种部署方式我都用过各自适用场景不同。第一种是单Pod双容器。Nginx容器负责静态资源Tomcat容器负责动态处理两个容器共享一个Volume来交换数据。这种做法的好处是Pod内部网络延迟极低Nginx反代Tomcat只需要走localhost坏处是两个容器生命周期绑定在一起动态和静态无法独立扩容。适合那种动静比例相对固定的业务系统比如后台管理系统。第二种是拆成两个Deployment各自带Service。Nginx通过Service名访问Tomcat比如http://tomcat-svc:8080。这种做法的好处是Nginx和Tomcat可以分别扩副本、分别更新坏处是多了Service这层网络转发延迟略有增加而且如果两个Service之间网络策略没放开反而会踩访问不通的坑。适合动静比波动大、需要弹性伸缩的业务。第二种方式下Nginx的配置示例是upstream tomcat_pool { server tomcat-svc:8080; } server { listen 80; location /static/ { root /usr/share/nginx/html; } location / { proxy_pass http://tomcat_pool; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这里upstream只能写tomcat-svc这个Service名不能写具体Pod IP。K8s集群里Pod IP是动态分配的靠Service负载均衡。如果你图省事写Pod IP今天能通明天Pod一重启就废了。还有一点要提前想清楚的是Session会话。默认的Tomcat Session在本地内存Nginx转发到哪个TomcatSession就存在哪个Tomcat上。如果后面遇到某台Pod重启会把这一批用户的登录状态全丢了。解决思路有几种把Session存Redis、用Ingress的负载均衡策略开IP哈希、或者给Tomcat集群加Session复制。形形色色的方案各有利弊但最推荐的是Session外置到Redis这又往回呼应了为什么之前要求先把Redis稳定性做好。3.3 LNMP架构的K8s化Nginx、PHP-FPM、MySQL三兄弟各就各位LNMP在K8s里的部署和传统虚拟机上的区别在于三个组件变成了三个独立的控制器管理对象Nginx用DeploymentPHP-FPM用DeploymentMySQL用StatefulSet。部署思路是项目代码挂到一块共享存储上Nginx和PHP-FPM都访问同一个路径。Nginx收到请求凡是以.php结尾的就通过fastcgi_pass转发到PHP-FPM的Service。这里有个中文站点经常踩的细节Nginx配置里的fastcgi_param参数一定要把SCRIPT_FILENAME指向共享存储里的绝对路径PHP才能正确找到脚本文件否则会返回File not found。PHP-FPM容器的选择也有讲究。直接用官方php-fpm镜像跑不了业务因为缺少业务依赖的扩展。正确做法是构建一个自定义PHP镜像在官方镜像基础上用docker-php-ext-install把需要的扩展装上比如mysqli、pdo_mysql、redis、gd这些。这类Dockerfile最好跟着业务仓库走版本和扩展列表一起管避免生产环境和代码不匹配。LNMP的MySQL和前面讲的一样不重复展开。只提醒一个容易忽略的点PHP服务访问MySQL时不要用Pod IP要用Service名端口。K8s内置DNS服务会解析这个服务名在集群内任意节点都能访问。域名解析虽小很多服务间调不通的问题最后都定位在这里。4. 微服务与入口流量Dubbo和Ingress的路由编排4.1 Dubbo微服务在K8s里的注册发现适配Dubbo是经典的服务框架它的核心思想是服务提供者启动时把自己注册到注册中心服务消费者从注册中心拿到服务提供者列表然后直连调用。在K8s环境里原来的Zookeeper继续扮演注册中心但有一件事变了服务提供者所在的IP变成了动态的Pod IP。这带来一个连锁问题。传统机器部署时Dubbo注册到Zookeeper的地址一般是固定内网IP消费者拿到后直接调用。K8s里Pod每次重启IP就变如果Dubbo还是注册自己看到的宿主机或容器网卡信息注册中心里的数据就是错的。Dubbo支持通过环境变量或JVM参数强制指定注册IP。常见做法是把服务容器里的注册地址设置为Pod IP设置方式一般是提供一个启动参数或环境变量比如DUBBO_IP_TO_REGISTRY。更需要注意的一点是多个Provider副本时每个副本都注册自己的Pod IP消费者按注册数据负载均衡这没问题。但如果某些客户端的网络策略只放行Service网段不允许直连Pod网段就会导致消费者调不通。这个坑在跨命名空间、跨集群的微服务场景下特别常见。配置上建议给每个Dubbo服务把注册中心地址独立拆分不要把所有微服务都写死同一个Zookeeper连接串。这样后面切不同的中间件环境或者把Provider分组都不用修改代码重新发布。Dubbo版本能用高版本就尽量用高版本新版本对K8s原生服务发现的适配比老版本好太多很多让你挠头的坑在升级后就消失了。4.2 Ingress统一入口外部流量怎么优雅地走进集群Kubernetes里Service有ClusterIP、NodePort、LoadBalancer三种类型但每个业务都开NodePort显然不是长久之计端口号冲突先不说多域名、多路径的路由控制能力也很弱。Ingress就是补这块短板的它是一个七层路由层把外部HTTP/HTTPS请求按规则转发到不同服务。实际部署时Ingress至少有两个组件要分清Ingress Controller和Ingress资源。Ingress Controller是一个具体的负载均衡程序比如最常用的nginx-ingress-controller它监听API Server上的Ingress资源变化实时生成nginx配置并重载。Ingress是你写的规则清单两条规则例子apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress namespace: app annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: nginx rules: - host: demo.local http: paths: - path: /api(/|$)(.*) pathType: ImplementationSpecific backend: service: name: backend-svc port: number: 8080 - path: /web(/|$)(.*) pathType: ImplementationSpecific backend: service: name: web-svc port: number: 80这段配置的含义是请求打到demo.local以/api开头的转发到backend-svc的8080端口以/web开头的转发到web-svc的80端口。路径重写注解rewrite-target的作用是把/api前缀去掉再转发后端服务不用感知一把Ingress路径。这里务必要意识到后端服务收到的路径取决于你重写还是不重写nginx-ingress默认是带路径转发设置重写规则反而会丢掉前缀需求要确定清楚再配。Ingress Controller的部署位置也有讲究。测试环境可以用NodePort方式暴露生产环境一般通过云负载均衡器接入或者直接把Controller的Pod调度到指定节点上用hostNetwork监听80/443端口。不管哪种方式流量链路都是客户端到Ingress ControllerController按Ingress规则转发到ServiceService再把请求负载到Pod。排查问题时沿这条链路一层层看很快能定位到卡在哪。4.3 验证入口和微服务联通的简单方法Ingress配置完别急着写一堆断言先手工验证三步。第一步本地或测试机能解析域名到Ingress Controller的地址。没有正式域名的环境可以在测试机器上临时改hosts。第二步用curl带Host头直接访问Ingress Controller比如curl -H Host: demo.local http://控制器地址/api/ping看是否返回预期结果。这一步能确认Ingress转发规则是否生效。第三步进入一个Pod内部通过服务名访问后端服务比如kubectl exec进某个Pod执行curl http://backend-svc:8080/ping确认Service层面是通的。这三步分别验证了外部路由、Ingress规则、内部服务发现哪一步不通就集中查哪一段。联调Dubbo时也有一个很实用的经验先在一个Pod内放一个简单的Consumer工程明确指定注册中心地址启动后看日志里能不能拿到Provider列表。拿到列表但调用失败通常是网络策略或者Dubbo直连端口限制拿不到列表通常是注册中心不通或者Provider注册的是不可达地址。按这个方向查效率会高很多。5. 常见问题与排查技巧实录这些坑我基本都踩过5.1 Pod一直Pending的排查路径Pod状态Pending最常见原因是资源不足或存储未就绪。第一步先看事件kubectl describe pod 名称最下面Events里有FailedScheduling字样把原因写得明明白白。比如0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory说明节点资源不够扩容节点或者调小requests都能解决。如果有persistentvolumeclaim not found或者waiting for a volume to be created说明PVC绑定有问题先检查StorageClass是否存在动态供给是否开启。这个问题的根源往往是requests设置太高而集群资源池不够或者是忘了创建StorageClass导致动态供给无法执行。遇到Pending别急着删除Pod反复重提先把日志看清楚事件信息99%已经告诉了你答案。5.2 服务间访问超时的问题定位服务间访问不通最经典的排查路径是从下往上打先检查Service有没有选对Podkubectl get endpoints 服务名看Endpoints是否为空。为空说明Service的selector没有匹配到任何Pod标签写错是最常见的原因比如应用Pod的标签是app: nginx-webService里写成了app: nginx-noweb完全对应不上。再检查Pod是否Readykubectl get podStatus不是Running或Ready的排除掉看ReadinessProbe有没有通过。很多服务OpenAPI端口和健康检查端口不是同一个探针路径配错容器明明活着但就是不Ready流量永远不会进来。然后检查DNS和网络策略从其他Pod里直接nslookup服务名确认解析出来的IP和Endpoints一致。如果集群启用了NetworkPolicy还要确认为什么访问被拒。NetworkPolicy没放行会导致规划外拦截表现就是同样的地址有时通有时不通非常迷惑。5.3 容器一直重启的问题排查CrashLoopBackOff是看起来最吓人、实际上最好查的状态。核心思路是为什么容器活不下来。执行kubectl logs 获取容器日志如果是配置错误日志里一般有明确的提示。比如MySQL密码校验失败、Redis配置里格式错误、Zookeeper连不上对端。然后看kubectl describe pod 的Events如果是OOMKilled说明内存Limit设置过小被Kubelet杀了调大Limit或者优化JVM/Redis内存参数。如果是Liveness探针失败说明健康检查配置和实际应用不匹配先确认健康接口路径、端口、初始延迟这三项。还有一个很多人忽略的情况容器启动脚本阻塞在前台。比如在Dockerfile里用了CMD执行一个脚本脚本内部先做初始化等待再启动主进程但脚本写成了死循环等待主进程永远没启动。容器默认认为只要进程在跑就是健康的实际业务根本没有就绪。解决办法是给容器配readinessProbe用真实的业务接口来量健康而不是进程号。5.4 数据安全相关经验的汇总在有状态组件的实际运维里有几点是拿时间和事故换来的经验。第一StatefulSet里的PVC不要手动删除。删StatefulSet不删PVC数据还能保住一旦顺手把PVC删了数据卷没绑定整个底层存储就找不回来了。第二数据库实例所在Pod迁移后要确认底层存储确实支持多节点挂载。对于只能单节点读写的存储类型Pod漂移到别的节点会导致数据盘挂不上Pod一直Pending。第三持久化数据一定要定期备份K8s不负责备份PVC不是保险箱底下一个误操作照样丢。很多云厂商和开源工具都能做定时快照哪怕先接一个最基础的cronJob调用快照接口也比什么都不做强。后面再扩展的话可以在这个基础架构上继续加入日志采集、监控告警和CI/CD发布流水线。K8s这套东西单个组件是零件串起来才是系统。我个人的体会是与其急着追求最优配置不如先让整条链路完整跑通再逐步优化参数。把这篇里的每个部分都亲手部署一遍你会对整个K8s的工作原理有比看十篇文章更深的理解。