很多公司技术支持岗位的工作, 如配置域名, 部署环境, 修改复位配置, 服务重启, 扩容缩容, 梳理和完善监控, 根据开发的需要查找日志等工作, 需要和开发进行大量的沟通, 如什么是外网域名, 什么是内网域名, A name,C name, 防火墙规则该如何设定, 操作系统等基础环境需要什么依赖. 因为很多研发不了解运维的术语和知识点, 导致沟通困难, 效率很低. 而且这样的需求还很多, 把运维压的喘不过气, 占用了几乎所有的时间, 但是开发的需求可能还是迟迟不能满足.
这样的公司可能遇到了以下问题:
系统架构过于陈旧, 性能, 可靠性无法满足现有的需求;
原有 IT 架构不灵活, 业务模块新增或变更带来巨大成本压力;
系统功能繁杂, 结构紊乱, 定制的代码与系统耦合性极高;
服务种类繁多, 各种技术栈横行;
人员流动交接不充分, 新接手的团队对部署环境不了解, 只能做周边的修补, 不敢迁移 .
如何才能解决? 答案是流程化, 标准化, 自动化, 平台化.
流程化
即主动梳理运维工作任务, 形成标准化的操作流程, 尤其是针对需要多人协作完成的任务, 比如应用的发布部署, 把流程固化到流程平台系统中, 保证每个人执行都能按照流程严格执行, 不会有哪些环节遗漏, 而且当前的流程状态对所有人都可见, 能清晰的看到谁正在处理, 处理人也会更主动尽快的完成该任务.
标准化
从架构角度按照应用类别制定应用的部署标准, 比如 web 类型的应用, 服务化的应用(我们内部用的. NET Core), 或者是比较新的微服务的应用(.NET Core 等), 部署脚本和工具平台按照约定好的规范进行设计开发(基于 Kubernetes), 减少了因为应用种类繁多导致工具和平台的复杂.
自动化
很多公司早期写了非常多的脚本, 任务执行机到要执行任务的服务器之间通过 SSH 免密钥认证, 再根据需要批量执行命令. 随着服务器规模和应用数量的扩张, 很快脚本执行的方式无法满足业务发展, 难以理解, 同一个类型的任务多个脚本并存, 存在误操作, 缺乏清晰的操作历史记录和回滚机制, 即使后续替换了如 Puppet,Saltstack,Ansible 这样的配置管理工具, 但根本问题并没有解决.
平台化
平台化一定要在前面三条的基础上进行建设, 如果没有清晰的流程, 明确的标准, 平台建设起来也只是自动化工具的集成, 解决不了公司核心问题.
以下说的平台化内容主要是 PaaS 平台化, 即主要从应用和中间件的角度, 这里不讨论 IaaS 的内容.
PasS 平台化将问题的关注点从基础资源上升到了应用层面, 目标是提供一个帮助开发人员运行, 管理应用的平台, 让使用者更关注运行的代码(业务逻辑).
PaaS 能解决的问题:
应用聚合: 如开发需要一个 Redis, 直接启动一个 Redis 容器即可
服务发现, 快速伸缩, 状态管理等
服务监控, 恢复, 容灾
安全管控: 不管什么平台, 安全都非常重要, 例如 A 应用可以访问 B,B 不允许访问 A 以及安全审计等.
快速部署.
随着 Docker 容器技术的出现, 让我们有了更合适的工具建设 PaaS 平台, 具备了基于应用构建服务的能力. 在 Docker 容器调度框架上, 我们自然选择了 Kubernetes 平台. Kubernetes 具有资源调度, 服务发现, 服务编排, 资源逻辑隔离, 服务自愈, 安全配置管理, Job 任务支持, 自动回滚, 内部域名服务, 健康检查, 有状态支持, 运行监控 / 日志, 扩容缩容, 负载均衡, 灰度升级, 容灾恢复, 应用 HA 等. Kubernetes 的核心是如何解决自动部署, 扩展和管理容器化 (containerized) 应用程序.
下图是一张最小化的 PaaS 架构图:
最上面的 Ingress 服务跟传统的负载均衡器的功能类似, 提供请求分发的功能, 分为两类: 对外提供 API 服务的 API 网关以及对外提供服务的站点, 对外的 API 网关采用 Ocelot 进行开发, Ocelot 完成了对 Kubernetes 的集成工作, 这个功能已经在我们的平台上工作一段时间了, 上个月把代码合并进入 Ocelot 主干, 已经可以通过 Nuget 包下载, 具体参见 kubernetes 客户端 KubeClient 使用及常用 API.
Service 相当于后端 Pod 的一个代理服务器, Service 需要通过 Ingress 服务才能被外部 Client 访问, Service 提供了服务的注册和服务发现.
Pod 则相当于我们传统的一个服务.
最小化 PaaS 平台还用到了 DNS 组件, 在内部服务运行起来之后, 我们会通过 DNS 组件分配一个内部域名供访问时使用.
Kubernetes 选用腾讯云 TKE ,TKE 服务在集群内默认启用了基于腾讯云负载均衡器实现的 l7-lb-controller, 支持 HTTP,HTTPS, 同时也支持 nginx-ingress 类型, 可以根据业务需要选择不同的 Ingress 类型.
平台关键能力说明
应用持续部署, 平台实现快速, 可视化自动部署功能. 支持对应用的快速, 可视化部署. 用户仅需在界面中选择相应的镜像和组件, 并填写简单的配置信息, 点击部署按钮, 即可完成整个应用的安装或者升级.
应用弹性伸缩, 构建具有需求预测和容器按需供给能力的弹性伸缩子系统, 具有基于应用的负载和资源情况进行弹性伸缩能力, 以应对互联网用户高并发的特点, 应对流量冲击. 其中, 包括容器弹性伸缩, 物理机弹性伸缩功能.
容器和组件的统一管理, 从整体应用的角度出发, 平台不仅管理镜像和容器, 而是将一个应用涉及的所有组件均做了统一管理, 通过对系统相关组件和容器统一管理, 平台将可以实现系统的全局统一部署, 配置, 升级 / 回滚, 监控, 故障处理等功能.
高可靠性, 容器的故障恢复, 当服务器宕机时, 平台系统会自动在其它服务器上重新启动容器并为其分配资源, 从而达到秒级启动, 恢复业务. 保障业务不掉线, 高可靠运行;
应用 Docker 化封装, 系统支持如下几类常见应用:.NET Core,Jexus,Nginx,Redis,MongoDB 等.
PaaS 平台功能组件
具体实施时, 主要有几个基础组件需要开发:
镜像管理, 实际运行的应用镜像由 "基础中间件镜像"+"应用包"+"配置" 自动构建, 借助于 Visual Studio 2017/2019 以及 Visual Studio Code, 以及微软开源的 Helm,Draft, 通过标准化内部培训, 让开发人员快速理解镜像概念和制作镜像以及开发流程;
DNS 管理, 定制化公司内部使用的 DNS 管理平台, 对公司的 DNS 进行统一管理;
服务管理, 需要定制化一套 Kubernetes 的 Deployment 模板, 从 Ingress 到 Service 再到 RC 都定义在这套模板里面, 方便对容器进行扩容, 缩容, 删除操作;
服务内 Pod 管理, 属于 Kubernetes 自有范畴, 查看 Service 内的 Pod 运行情况, Pod 日志输出等功能;
日志管理, 将日志输出到公司的日志平台(如 ELK 平台), 对接研发人员排查问题, 数据埋点使用;
监控管理, 参考方案: cAdvisor + InfluxDB + Grafana/ Heapster + Grafana/Prometheus/Zabbix:https://www.cnblogs.com/Cherry-Linux/p/9144650.html.
虽然我们属于创业公司, 我们相信技术的力量, 技术帮助我们实现业务的持续健康发展, 从发展的初期就规避很多公司的一些困境, 一个中小企业做成这样后, 日常运维的工作量即可大量减少, 两三个人就能完成日常的应用运维工作, 有兴趣地话可以去挑战一下. 当然做完这些后, 还只是一个小型的 PaaS 平台, 我们基于腾讯云的 TKE 平台构建这样一个小型的 PaaS 平台.
如果是再复杂一点的 PaaS 平台, 应该还有哪些要继续做的呢? 环境管理: 即一套平台管理多套不同的 Kubernetes 集群, 安全管理, 流程管理, 计费管理等功能模块. 还有因为规模增加和更高的可靠性要求, 对应的网络, IO 等各种优化. 其实还有很多功能就不一一列举了, 可以根据自己的实际情况添加功能模块, 设计有自己公司特色的 PaaS 平台.
来源: https://www.cnblogs.com/shanyou/p/10658110.html