随着云计算和虚拟化技术的快速发展,容器技术正逐渐成为现代应用程序部署的首选方案。对于传统企业来说,采用容器化技术可以帮助实现应用程序的现代化、跨平台部署、弹性伸缩、敏捷开发和交付,以及提升应用程序的安全性和隐私保护。这将有助于传统企业更好地适应市场变化和提高竞争力,传统企业容器化过程中,往往会面临一些互联网企业无需面对的问题。本文介绍了国内某车企容器化的选型和使用经验以及目前存在的一些痛点问题和未来发展规划。
随着企业信息化的发展,IT应用不断增加,对服务器及运维资源的需求量呈爆发式增长。利用率及效率问题也随之暴露出来,服务器及运维资源利用率、宕机故障发生率、处理及时率等方面存在很大的提升空间。早期公司借助物理机虚拟化技术,在一定程度上降低了服务器运维的复杂性,增加了资源的利用率。但应用依然面临严峻的问题:
基于以上问题,我们决定引入容器技术,建设容器云平台。
建设目标:
公司从2019年引入容器技术以来,经历了多次容器平台的实施。在容器化、微服务化、Devops、容器化中间件、虚拟机容器化等领域形成了一定的基础能力。
传统企业推进容器化负担较重,在容器技术在内部推广过程中碰到一系列问题:
在容器化平台选型上主要考虑:
基于以上考虑的维度,我们对比了开源Kubernetes、rancher、OpenShift等一些平台,最终选择OpenShift作为平台的基座,OpenShift具备以下优势:
公司从2019年引入容器技术,技术上经历了无状态业务、中间件服务、大数据类业务的容器化实现,业务上完成了从自研的Java类服务到外采服务包括(Windows)的覆盖。在基础设施环境上覆盖了从国内到海外、中心到边缘的全面覆盖。
2019~2020: 引入容器化技术,进行项目试点,通过CICD工具打通应用的部署流程;
2020~2021: 全面推广应用容器化、建设容器化中间件能力、建设Devops平台;
2021~2022: 建设微服务平台能力,引入Istio技术进行服务治理;
2022~2023: 建设大数据类服务能力、边缘数据中心场景的覆盖;
2023~至今:建设混合云场景下以容器技术为底座的混合云平台。
公司在整个容器发展过程中经历过很多,这里介绍几个我们在容器化过程中碰到的一些问题以及对应的解决方案。
公司内部存在大量的Windows服务,早期都是以传统进行发布运维:
借助OCP CNV技术完成了虚拟机和容器的统一管理,虚拟机提供两类服务:
借助CNV对VM和容器的集中化管理,完成了容器平台对Windows服务的收敛:
公司内OCP集群的安装主要由基础设施提供,以公共集群方式对业务部门提供服务。此类方式存在一些痛点:
通过我们的调研,通过红帽提供的HyperShift 和CNV技术可以满足在不同基础设施的情况下实现OCP集群的托管。用户可以方便的拉起和销毁、运维OCP容器底座。借助此项技术,10分钟内在任何环境搭建一套OCP集群并且可以满足业务独立OCP集群的需求;
公司内部基于红帽StackRox产品对于容器安全进行统一管控,目前对于容器安全的建设主要分为几个方面:
4.1.1运行时安全
通过Kubernetes SecurityContextConstraints严格控制容器内用户的权限,比如运行用户和用户组、文件系统访问权限、特权模式限制。普通业务只拥有最低级别的权限,按需申请。
通过StackRox产品对容器通过实时监测和分析容器的运行时行为,检测和防止容器中的潜在威胁和漏洞,包括恶意代码、容器逃逸、容器漏洞等。
4.1.2网络安全
落地OpenShift平台时,严格限制业务的网络访问。
4.1.3应用安全
在日常的容器运维过程中,积累到一些最佳实践的内容,简单分享几点:
1. 容器集群自动化运维
容器平台除了考虑稳定性的因素,随着集群规模越来越大,集群数量越来越多,容器集群本身的运维必须能够自动化。我们在容器集群的日志、监控、备份、扩容、资源交付等方面都开发了对应的operator,通过operator打通IAAS层资源以及公司内部的CMDB、自动化交付平台,可观测性平台等外部系统。不仅提升了运维的效率,也方便标准化管理。
2. 定期进行故障演练
随着容器平台引入的东西越来越多,技术越来越复杂,故障点增高的同时也变得越来越复杂。为了最大程度上降低故障出现的频率和造成的损失,我们采取主动演练的方式定期对平台以及业务进行主动的故障制造。这些手段包括人为的停机或者断流、主动的安全攻击,我们也在尝试使用混沌工程的一些开源项目例如Chaos进行更为系统全面的故障注入方式。通过演练,不仅整改了问题项,同时也提高了工程师的排障能力,对系统的稳定性更为有信心。
3. 应用可观测
在公司内部业务容器化的过程中,我们发现容器化业务对于可观测性的要求相比传统运行在虚机的业务更高。一方面是因为部分业务开发人员对容器技术不够熟悉,另一方面是由于容器的动态和自动化程度过高导致。除了日志、指标、链路追踪等基础知识,我们为核心业务系统建设了包含虚拟机、网络、负载均衡、应用服务器、数据库、中间件、应用等维度的统一大盘,聚合和联动容器的日志、指标、事件等信息,为业务的故障排查和预测提供了很好的支撑。
1. 出向流量安全管理
我们通过networkpolicy能够很好的控制Kubernetes集群内部的流量调用,隔离业务系统之间的服务调用。然而,容器里的服务不会只在集群内部封闭运行,它需要访问集群外部应用、数据库、第三方API服务、互联网服务等。出向流量里可能包含业务需要的外部访问,开源组件更新的访问,也有可能是入侵应用对外的一些访问。从安全的角度出发,必须能够对容器内的服务进行出向流量的控制,传统模式下通常通过IP地址进行防火墙或者黑白名单的设置达到控制访问的目的。但由于容器的动态性,IP地址发生变化,必须使用其他方式进行细粒度的控制。
由于EgressIP、Egress Router Pod都存在性能瓶颈,我们最终使用Egress NetworkPolicy方案。在项目初始化时,通过项目模版生成规则,默认deny掉非必要的所有外部访问、结合运维管理流程,业务按需进行IP地址或者域名的开放。
2、节点管理
目前运行在OCP平台上的业务类型分为无状态服务、中间件服务、大数据类的服务。不同节点对于机器配置、存储、稳定性以及内核参数的要求不一致。目前集群内除了Master以外管理了几类不同的节点池:
1). 基础设施节点
部署容器集群基础设施类服务例如日志、监控、微服务管理服务、集群和中间件的operator服务、云控制器服务
2). Route节点
多组七层网络入口服务,每组Route服务通过水平扩容的方式扩展流量承载能力。通过Router分片方式,当集群内路由数量超过一定阈值(5000),创建新的一组Router节点
3). 普通工作节点(包括无状态业务服务、大数据类服务)
无状态服务以Java居多,对于内存的需求量较多。节点的规格cpu和内存的比例设置在1:4。跑在此类节点上的服务必须具备随时被驱逐或者调度的情况下也能实现服务高可用的要求。同时为了提高节点资源的利用率,将Spark、Flink等大数据的Job类服务也调度到此类节点。
4). 中间件节点
中间件对于稳定服务的要求比较高,应该尽量避免重启或者调度的操作。由于ocp通过machine管理节点的方式要求每次节点都必须进行重启,所以此类节点的machineconfig自动更新设置为暂停。以人工干预的方式进行此类节点的升级。通过自定义调度器,实现中间件类的Pod都会被调度到此类节点上。
5). 存储节点
使用ocp的ocs作为块存储和文件存储的服务,存储节点应尽量避免被其他业务干扰,同时可以做到灵活的扩容。此类节点的自动更新也被关闭
3、集群标准化
我们在不同的数据中心按照业务环境划分了不同的OCP、OKD容器集群。集群数量多了以后,多个集群的统一管理和配置给运维造成了不小的负担,人工方式配置集群也会给稳定性带来一定的挑战。关于集群的统一管理,我们也做了一些工作:
1). 通过OCP统一纳管不同的集群,实现统一的集群管理和API管理入口;
2). 通过GITOPS实现集群配置的统一下发,比如一些策略配置、集群设置等;
3). 将内部的一些自动化Operator、中间件Operator封装成内部的index镜像,管理这些operator的安装和更新;
4). 汇聚所有集群的监控、事件、日志、运营等数据到外部平台,统一管理集群的观测性和运营数据。
4、统一流量调度
早期每个OCP集群都有自己的Ingress网络入口,业务发布在不同环境需要配置不同的DNS解析和证书。为了收敛,我们建设了统一流量入口服务。统一入口提供证书卸载、安全防护、限流熔断等基础能力,容器后端的Ingress入口作为流量入口的公共upstream,配置泛域名解析,业务只需在配置时选择对应集群和服务即可完成流量的配置,在业务迁移时也借助公共的负载配置一些灰度迁移的能力。
容器平台上线后,覆盖了公司研发、采购、供应链、销售等多个领域共计200多个业务系统。给业务部门带来的收益如下:
7.1.1对比容器多集群的社区开源项目
除了上述业务的需求,另外容器单集群本身存在的的稳定性和容量上限、不同云环境的版本不统一等问题,容器的多集群管理是必须解决的问题。我们对比了多个多集群的社区开源项目:
通过对比在功能层面上Karmada吸收了参考Kubernetes Federation v1 v2 两个版本的核心实践,并融入了众多新技术,包括 Kubernetes 原生 API 支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等,并且提供原生 Kubernetes 平滑演进路径。在可扩展性、现有平台兼容性都满足我们的需求。
3. 联邦业务调度:
结合多集群的发布能力以及全局流量平台的建设,满足业务不同的发布需求。
公司内部存在大量的外采系统服务于研发流程,比如Devops、原型设计、低代码平台、微服务平台等,系统落地后往往在初期能够收获一定效果,但烟囱式的系统建设方式导致用户面向的系统越来越多,不同系统之间门户独立且无法集成。业务无法以统一视角闭环业务开发流程,应用需要再需求管理、开发、发布、运维等多个阶段使用不同的平台,这些平台之间目前缺乏联动,用户使用起来十分不便。
建设思路: 我们考虑建设统一门户,将外部系统的能力抽象成原子能力服务,同时建设部分原子能力,例如:持续集成、代码管理、注册配置中心、服务治理、中间件等,以类似公有云的服务方式对外提供服务。同时,以企业元数据为基础串联系统设计、研发写作、持续交付、资源管理、监控运维多个阶段。这里的企业元数据是指公司的产品、服务、应用的数据。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞16
添加新评论4 条评论
2023-10-12 00:17
2023-10-11 14:56
2023-10-10 19:15
2023-10-10 17:29