这是一个前端 第一次涉及到集群 可能有很多不成熟的地方 也走了很多弯路 这篇就是现总结下目前成功部署需要注意的本文的环境是使用阿里云ACK托管集群项目结构是ecs中台管理器ecs前端mongodb数据库集群中目前暂时一个节点服务器 后台服务集群基本环境搭建中台连接集群~/.kube/config 下面配置文件 单集群 如果后期要多集群切换的话 --kubeConfig指定配置文件切换集群 或者其他方案 这个后续研究~安全组配置 集群的安全组入方向开启VPC内网 6443 和 中台管理器内网IP 6443前置条件中台服务器 集群 集群节点需要在同一个VPC下面 集群节点添加到集群中 需要在被添加的节点服务器上 运行云厂商命令 成功后 使用kubelet 查看基本上查看当前集群 服务器节点运行 和 节点服务器是否正常kubectl get nodes -o wide 查看集群下所有服务器节点的状态 kubectl get pods -n kube-system -o wide 查看集群下核心组件的状态 核心组件一般都在kube-system 下面 terway网络插件的状态 kubectl get pods -n kube-system -l appterway-eniip 查看 Terway DaemonSet 状态 kubectl get ds -n kube-system terway-eniip部署结构 1. 后端sh自动化脚本打包镜像 推送ACR镜像服务地址 需要在ACR里提前建好命名空间和镜像仓库 并注意推送的时候写好版本号 可以在sh中使用变量${version} 每次执行时 动态传入变量 sh xxx.sh 版本号后续更新部署的时候 sh更新版本号 ACR控制台看到新版本镜像中台管理器运行 滚动部署kubectl set image deployment/你的部署名 你的容器名新镜像地址:新版本 -n 你的命名空间kubectl rollout status deployment/你的部署名 -n 你的命名空间 查看当前滚动更新的状态2. 后端集群部署的deploy svc 里 连接 ACR地址 要注意 个人版的ACR 拉取镜像最好配置VPC内网地址业务连通1. 集群需要访问外部服务 mongodb实际链路流量走向 pod -------节点 ----------- VPC------------目标ecsmongodb安全组入方向1放行集群pod 交换机网段2VPC内网网段并且要在worker节点上配置好 addroute mongodb 内网ip via VPC子网默认网关安全组是为了开启mongodb接受访问的入口addroute增加路由表 是因为pod访问外部服务terway 网络 将worker配置eni 走策略路由 但是外部的内网ip不在路由表里 需要在pod--worker对应的路由表下kubectl get pods -o wide -n 查看pod-ipip rule show 查看每个流量对应的路由表ip route show table [] 查看指定的路由表同时也要增加安全组配置 mongod服务器 入方向 允许 terway默认子网网关的访问 pod虚拟交换机的ipv4网段 如果有多个虚拟交换机需要配置多条# 查看 Terway ConfigMapkubectl describe cm -n kube-system eni-config 可以查看下面的vswitches字段 交换机id 根据交换机id 查看pod网段后期就算replicas设置成多个 pod ip依然会在网段内策略路由时为了告诉pod 流量从哪块网卡发出放行mongodb的接受通路2. 外部ecs服务器访问pod内部服务请求的链路前端-》默认网关-》VPC网络-》worker节点-》kube-proxy--》pod节点外部到cluster ip 关键节点VPC路由表里是否有 集群 service CIDR 下一跳 worker ecs节点的路由 将访问集群的流量直接转发worker通路是为了打通实际流量走的通路 明确访问集群的走workerkube-proxy组件是否正常运行 服务分发 将cluster-ip 转为pod-ip 到达pod内部iptables-save -t nat | grep 【pod-ip】 如果返回为空 说明流量规则没有走到pod kube-proxy运行不正常 则重启kube-proxy组件pod-ip是 kubectl get pods -o wide -n [命名空间] 查看打通前端出方向--》集群 cluster ip cluster ip只要不重启service 就不变查看worker节点到pod的通路ip route show table 1004 | grep service 网段 查看 是否有service网段到默认网关的规则 一般是Terway CNI 组件自动生成的“去往192.168.0.0/16Service 网段Pod IP 属于此范围的流量从eth0网卡发出下一跳发给网关172.23.239.253。”集群入方向《--------前端 内网ip排查方向抓包工具tcpdump的妙用可以在前端执行telnet请求 前端进行 抓包 如果有包 说明前端出方向正常sudo tcpdump -i eth0 host cluster ip and port 3300 -n在worker节点抓包抓service ip的包 看请求是否到达了worker节点抓pod ip的包 看请求是否kube-proxy转发正常关于网络暴露模式于后期维护网络暴露模式规定的是如何让外部访问节点的服务cluster ip流量路径客户端 → VPC 路由 → Worker 节点 (目标 IP 仍是 ClusterIP) → Pod目前使用的是cluster ip 即流量转发到指定的一个worker 在VPC路由里设置 下一跳到worker ip 即使后期多个replicas 也可以通过这种方式 安全组也不用调整因为是流量-----》worker -----kube-proxy分发 pod节点所以入方向还是前端的ecs mongodb入方向还是pod网段loadBalancer流量路径客户端 负载均衡 worker节点 pod客户端 → 负载均衡器 → Worker 节点 (目标 IP 已是节点 IP) → Pod所以不需要像cluster ip模式一样在 VPC路由里面配置service cidr下一跳指定worker节点 因为负载均衡已经自动分发到worker节点了使用于多个worker节点 在集群入方向的安全组设置 原本设置的前端ecs 必须改为worker节点的ip 因为是通过外部负载均衡转发到worker 安全组校验的worker是否可以接受指定的外部流量 可以是worker 节点每个具体ip 或者整个VPC网段因为loadBalancer安全组校验的是目标ip当然从外部到worker worker到kube-proxy分配pod 有可能会分配到一个pod 配置podAntiAffinity 防止挤在一个pod sessionAffinity: ClientIP会话保持配置反亲和性配置nodePortnodeip直连 安全组也是所有worker ip 负载均衡需要手动配置可以在nginx转发里配 或者openresty lua脚本配置 也就是说nodePort是到worker的直连cluster ip service CIDR pod Ip 概念使用场景区分cluster ip 是每次在apply service时 在 service CIDR范围内生成的IP用于 集群外部 访问 集群的地址 比如 前端访问后端集群 nginx配置的地址就是 cluster ip的地址service CIDR是所有 cluster ip的段所以用于在VPC路由里面设置下一跳 对流量走向进行统一约束pod ip是每一个pod节点的ip在pod 访问外部服务的时候设置安全组使用 但是pod ip 每次随机生成的 不能直接设置pod ip需要拓宽到pod 网段 即上面提到的交换机所在的网段