南山行者
作者南山行者2020-12-09 14:29
系统工程师, 某银行

证券行业生产环境容器云平台规划架构设计探讨问题总结

字数 17638阅读 3659评论 0赞 5

本文由社区专家 wykkx 整理。


随着证券行业的发展,支撑业务的IT系统也在逐渐壮大。为了快速响应业务需求,敏捷交付成为了IT系统建设新的要求。容器技术作为敏捷交付的最佳拍档,券商已经陆续开始在生产环境部署规划容器云平台,支撑如融资融券、行情等生产应用。

对于容器平台的建设,从初期就需要做好平台的整体规划,切莫为了容器化而容器化,需要因地制宜,寻找平衡点逐渐落地,混合实施,了解开发运维等多方面的需求、平台相关技术的原理机制,团结开发、运维、用户等才能共同设计好一个容器平台。

目前看来券商容器云平台架构规划设计阶段可能面临如下挑战:

· 大多数容器云平台用来承载微服务应用,其pod数量会呈突发式增长,如何保障平台的稳定性和高可用性;

· 容器云平台如何和已有监控系统进行对接;

· 容器云平台如何选择网络模式。

为了帮助大家了解以及如何更好地面对这些挑战,twt社区组织了本次活动,并邀请安信证券和Rancher的专家进行分享和答疑。欢迎各位证券行业的容器云架构师和工程师报名并参与本场活动,可将相关的疑难问题发布到本活动平台上,与同行及专家进行在线的交流。

以下是本活动“证券行业生产环境容器云平台规划架构设计探讨”的交流问题的总结梳理,供大家参考!


一、容器云基础架构相关

【 Q1 】 在面对满足券商监管要求、高性能、稳定、易维护性、可扩展性的要求下如何选择合适的容器网络解决方案?

容器网络的架构与原有经典的三层架构区别较大,如何设计容器的网络架构使之能在保证网络的高性能、高可靠性、易维护的前提下还能满足监控、合规、风控、审计的要求?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

面对金融监控要求容器云网络一般都会要求:

1 、 POD 拥有跟数据中心同二层网络 ip 。

2 、 POD 需要能够固定 IP 地址,因为针对跨网络分区应用访问需要添加防火墙白名单。

因此这类需求目前都需要一些 underlay 的网络插件能解决,如 calico-bgp 和 macvlan ,但如果使用 calico-bgp 的话需要将 bgp 路由同步到数据中心的路由器上,不然防火墙无法对 POD 的 IP 开白名单,对于大部分金融客户来说基本上不太可能直接使用 calico-bgp 这种方式,剩下只有使用 macvlan 了,但直接所有 POD 使用 macvlan 会降低 POD 的灵活性和,并且 pod 的密度比 vm 的密度大得多,如果前期没有规划好,同一个 vlan 内 POD 数量过多,容易造成广播风暴。为此 Rancher 针对此类需求专门开发了双网卡的 CNI 网络插件 canal+macvlan ,它具有以下特点:


1 、一个 POD 内有两块网卡,默认情况下 pod 内之有一块 canal-vxlan 的网卡,可灵活跟据业务 POD 需求打开 macvlan 网卡。可有效避免所有 POD 全部使用 macvlan 网络。

2 、可在 UI 上对网络 macvlan 子网进行灵活配置,包括自定义 macvlan 子网、 ip 分配范围、自定义路由。

3 、可以整个 Kubernetes 集群网络分拆成两套网络 - 管理网络和业务网络,实现业务应用网络扁平化的同时也极大的提升了网络的传输性能。

4 、能够对 workload 指定 IP 和指定 mac 地址方便一些需要做防火墙流量白名单的应用场景。

【 A2 】 acbogeh 系统工程师 , 富国基金

macvlan 优点是固定 IP ,缺点是规模大的话维护路由表是个工作量。
Calico 性能比 MacVLAN 要差一点,但是 Calico 使用 BGP 可以方便的对接物理网络,有丰富的 Network Policy ,能够满足大部分要求。

【 Q2 】容器云平台双机房部署注意事项?

容器云平台承载生产应用以后,必然要面对双机房高可用部署这个问题,容器云部署双机房高可用,应该注意哪些问题

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

双机房部署容器云平台需要考虑机房之前的网络质量问题,主要是需要考虑 etcd 组件网络性能, etcd 组件对网络要求如下:集群 leader 选举超时应至少为 100 毫秒,集群成员间连接最大超时时间为 50 秒上限。

【 Q3 】容器云如何设计两地三中心部署微服务?

微服务注册与发现,如 Springcloud ,同城双活如何部署设计,异地灾备如何部署设计;注册中心需要部署几套?微服务发现,如何做到获取同城的服务?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

目前企业采用比较多的微服务框架主要基于 Dubbo 或 Spring Cloud ,服务注册中心一般是 eureka 、 zookeeper 以及后来推出的 nacos ,同城双活环境下,可以跨集群部署一套注册中心,微服务应用调用时优先调用同集群微服务,当同集群无可用服务提供方时,调用跨集群服务提供方。另外,当存在跨集群服务调用的情况时,在规划容器云网络时就要考虑跨集群网络互通问题。如果无法实现网络互通,可能就要采用访问代理或者灾备的建设思路。 kubernetes 本身也提供了原生的 service 功能,对于 kubernetes 环境下的 spring cloud 和 dubbo 的落地,也可以参考下官方社区的 spring-cloud-kubernetes ( https://github.com/spring-cloud/spring-cloud-kubernetes )和 dubbo-kubernetes ( https://github.com/apache/dubbo-kubernetes )项目,可以借鉴

【 Q4 】容器云平台落地过程中高可用性、备份恢复、监控告警、应用对外暴露如何实现?

容器云对大多数工程师还是一个比较新的技术,如何实现容器云的高可用、备份恢复、监控告警、应用对外暴露是运维工程师日常运营过程中经常遇到的问题。

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

你好,关于您的问题回复如下:
首先
高可用:

回复:对于 Kubernetes 来说主要关注 master 节点上几个核心组件的高可用如 api-server 、 Controller-manager 、 etcd 、 kube-scheduler

1 、 Etcd 通过本身的集群机制,组成 etcd 集群保证集群高可用;

2 、 controller-manager 、 scheduler 本身有 leader 选举机制保证高可用;

3 、 api-server 为组件访问 etcd 和外部访问集群的统一入口,本身为无状态的,所以通常情况下 HA 的做法是通过外部 LB 做为统一入口进行 HA

ps: 通过 Rancher 建自定义集群只需要选择 3 个 master 节点角色会自动进行高可用配置

备份恢复:

因为在 Kubernetes 集群中集群内定义的所有资源对象都是存储在 etcd 中,所以针对集群的备份和恢复本质上是对 etcd 的备份。原生的 Kubernetes 可以直接通过 etcdctl 进行备份和恢复,通过 rancher 管理的集群 UI 上有手动备份恢复和自动备份功能,帮助用户定期自动备份集群,保证集群可靠性。

监控告警:

容器云平台监控和容器应用监控主要使用 Prometheus ,告警可以通过 Altermanager webhook 方式对接自己外部的统一告警系统, rancher 已经内置了 Prometheus 监控包含多个层面监控包括:集群层面资源使用监控和组件性能监控、节点资源监控、容器应用资源监控。对于一些需要针对业务的监控可以使用自定义监控方式实现对业务指标监控。

应用对外暴露:

可以通过 NodePort 和 Ingress 若有 F5 硬件负载均衡器可以直接通过容器云平台与 F5 集成实现 F5 直接转发流量请求到 POD 中,这几种方式的对比优缺点如下:

通过 NodePort 进行暴露

1 、通过 Nodeport 四层暴露方式,需要在内网开防火墙

2 、端口随机且无法进行统一权限管理

3 、 iptables 模式规则过多,容易造成转发性能瓶颈

4 、四层转发,配置模式单一
通过 Ingress 进行暴露

1 、 L7 负载均衡器通过域名或路径区别转发到服务,统一转发到 Ingress-controller 转发到后端服务中

2 、防火墙只需要开通节点 80 和 443 端口

3 、需要配置 DNS 服务器进行域名解析

4 、可配置非常丰富规则

通过 F5 与集群对接实现应用对外暴露,通过 Kubernetes 策略自动生成 F5 规则

方式一: NodePort 模式

转发路径:

Internet --> F5 --> Worker Nodes/Ports --> Pod IP

此种模式有如下缺点:

服务必须使用 NodePort 方式暴露

某些高级应用交付功能不可用,例如 L7 的会话保持

额外的网络延迟

BIG-IP 控制器对 Pod 的健康程度等可见有限

通过 F5 与集群对接实现应用对外暴露

方式一: cluster 模式

转发路径:

Internet --> F5 --> Pod IP

这是一种更优雅的方式,优点如下:

可以使用任何类型的 Kubernetes service 。

完整的应用交付能力,包括 L7 持久性。

BIG-IP 控制器可以完全了解 Pod 的运行状况。

ps: 如果需要进一步了解可以加我们同事微信: x968807

【Q5】 容器环境的微服务如何进行链路可视化,通过 APM 工具的话哪些比较适合容器环境使用?

【A1】
目前容器环境下的微服务监控方案也比较成熟,可选择性也比较多,像商业的 Dynatrace 就能够很好的的实现从底层到应用层的全景监控,开源的方案目前比较主流的有 Pinpoint 、 Skywalking 、 Istio 等,其中 Pinpoint 和 Skywalking 主要采用 Java 语言开发,对 Java 生态有着非常好的支持,启动时通过 Java agent 的方式就可以快速集成,对于其他语言社区也提供了一些集成方案, Istio 这种就是目前主流的服务网格的方案,与语言无关,通过 sidecar 的方式集成,也可以实现微服务链路可视化。

ps : rancher 已经集群 istio ,可以直接在 UI 上查看应用关系调用。

【 A2 】 acbogeh 系统工程师 , 富国基金

容器的高可用大部分可以用 k8s 本身特性满足
监控段 promethus 可以满足
对外暴露的话也是 k8s 自身的 nodeport/service 就能满足

【 Q6 】容器云平台的弹性伸缩策略有哪些?

弹性伸缩,目前有哪些策略?每项策略的原理是什么?什么场景建议弹性伸缩?什么场景建议提前扩容?弹性扩容是否对数据库产生压力,该如何避免?两地三中心资源调度,该如何设计弹性伸缩策略?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

弹性伸缩,目前有哪些策略?

在容器云平台中实现弹性伸缩主要通过一个叫 HPA 的资源对象实现 实现策略主要通过 cpu 和内存的阀值检测扩缩容,但也可以通过自定义业务指标,如通过 QPS 设定的阈值进行弹性伸缩。

每项策略的原理 ?

通过 cpu 和内存值的扩容实现原理是:

1 、监控指标的获取

早期 kubernetes 版本是使用 hepster ,在 1.10 后面版本更推荐使用 metric-server

2 、 hepster 简单来说是 api-server 获取节点信息,然后通过 kubelet 获取监控信息,因为 kubelet 内置了 cadvisor 。

metric-server ,简单来说是通过 metric-api 来获取节点信息和监控信息。 https://github.com/kubernetes-incubator/metrics-server


通过自定义监控指标扩容实现原理是:
实现 prometheus 实现自定义 metric 来更加灵活的监控指标实现弹性伸缩。
1 、 pod 内置一个 metrics 或者挂一个 sidecar 当作 exporter 对外暴露。

2 、 Prometheus 收集对应的监控指标。

3 、 Prometheus-adapter 定期从 prometheus 收集指标对抓取的监控指标进行过滤和晒算,通过 custom-metrics-apiserver 将指标对外暴露。

4 、 HPA 控制器从 custom-metrics-apiserver 获取数据。

什么场景建议弹性伸缩?

建议一些无状态的,需要面临访问峰值,需要提前准备服务器,预防访问量增长造成的服务器压力过大业务配置弹性伸缩,如经常做秒杀活动的一些业务。

弹性扩容是否对数据库产生压力,该如何避免?

对于弹性扩容的应用多个实例副本连接后端数据库必然会增加后端数据库的压力,建议提前规划好数据库的资源和连接数,避免因为连接过多导致数据库性能问题。

两地三中心资源调度,该如何设计弹性伸缩策略?

目前容器云平台的弹性伸缩实现的范围只在本集群范围内

【 Q7 】如何保证外购容器化业务系统完美落地到容器云平台?

如何保证外购容器化业务系统完美落地到容器云平台?

【 A1 】 wykkx 系统架构师 , 某基金公司

说实话,这个执行落地比较难。外购的业务系统在做容器化输出的时候,都会考虑自包含,同时各个商用的容器云平台也会做产品级的调整,因此要完美的落地到每个公司自己的容器云平台,最好在 poc 测试阶段就进行测试验证,并且进行全面验证。

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

如果外购的业务系统已经是容器化的那其实工作量还是小很多的,因为现在容器化编排工具 Kubernetes 统一天下了,所以我理解只要对应的容器镜像和部署 yaml 文件或 chart 包就可以部署到容器云平台上了,但不排除有些容器化比较早的业务系统还是用的 docker-compose 的部署方式,那就需要做一些转化了,将 docker-compose 文件转换成 Kubernetes 的 yaml 文件。

举个简单例子

我们有个客户想把一套多年前买的云管系统上 Rancher 容器云平台,但因为是几年前的,所以当年的部署方式的是使用 docker-compose 方式部署的,所以客户找到厂商和我们一起,但由于厂商方并不懂 k8s ,所以 Rancher 先把一些 k8s 的一些基本概念和 k8s 与 docker-compose 区别进行了将解,后面由外购业务系统厂商将对应的 docker-compose 文件进行转换成 yaml 然后成功部署到容器云平台中。

【 Q8 】容器平台是否可以运行在华为鲲鹏 ARM 芯片服务器上?

容器平台是否可以运行在华为鲲鹏 ARM 芯片服务器上?,若支持,相对于同等性能 X86 服务器的性能表现如何?是否可以大规模应用

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

rancher 容器云平台完美兼容华为鲲鹏 ARM 芯片服务器,并且我们目前也在一些证券公司实施落地了,详细认证情况可以参考: http://ic-openlabs.huawei.com/openlab/#/unioncompaty?type=Commercial

二、容器云与 devops

【 Q1 】容器云平台如何与 DevOps 平台深度融合产生价值?

【 A1 】 jiangjf2DevOps 工程师 , 安信证券

容器化,微服务和 DevOps 是云原生架构的三个特征,三者的发展也是互相促进的过程。我们最开始尝试 DevOps 实践的试点项目是主要基于虚拟机来部署的,在环境的一致性、标准化,环境的准备时间,统一升级等方面遇到了很大的挑战。这些问题对于应用容器化提出了诉求。在容器云平台的建设推广过程中,也对通过 DevOps 工具平台来承载规范、流程,提高自动化,简化使用,降低门槛,更好的支持应用上云提出了诉求。因此从平台建设的角度来说,两个平台之间存在很多对彼此的需求。

在我们 DevOps 实践过程中,容器云平台首先为 CICD 工具的搭建提供了基础资源,通过容器云平台的监控和故障恢复机制来保证工具平台的可用性,这对于初期采用一些开源工具社区版本的方案来说是很好的支撑。其次容器云平台为流水线的建设提供了动态创建和回收的标准化的构建资源池,并为其在共享存储、资源隔离、监控等方面的需求提供方案。然后还为应用提供了快速准备开发、测试环境的能力,支持应用环境的标准化和一致性。

在应用迁移到容器云平台的过程中,流水线也提供了从特性开发到集成,构建、部署、测试整个过程的支持,不断完善着应用交付过程的流程和规范;同时迁移过程中各种资源的申请和工具平台的接入也向 DevOps 平台提出了提供自助服务简化工具平台的接入和资源申请的流程,减少人工审批环节,等待时间等诉求。

两个平台的建设是相对独立的过程,可能会由不同团队来建设,需要强调以应用视角来进行统一规划和考虑,避免在应用上云的过程中,需要学习各种工具平台,重复的接入和沟通。在建设初期这可能是一个比较容易被忽视的问题。容器云平台与 DevOps 平台的融合产生价值,需要以应用实践的效果来检验,最终体现在项目团队在质量、效率、成本、安全的改进上。

【 A2 】 gxcornflakes 信息技术经理 , 某金融单位

DevOps 在于轻量级流程,精髓在于自动化。
两者结合,通过自动化流程实现持续集成 CI 、持续交付 CD 、持续部署 CD ,让开发更注重于业务,提高效率,让运维通过编写脚本等方式实现自动化摆脱繁复的运维工作,提高工作效率,更注重于容量、性能、监控、排障等后台运维工作以及运维平台的思考和建设。
简言之:通过建设规范化流程,提升自动化能力,实现降本增效。

【 A3 】 wykkx 系统架构师 , 某基金公司

容器平台由于其天然具备的标准化基础,天然具备做 devops 的基础,这也是为什么很多公司在做 devops 的起步时会选择使用容器平台的原因。其次,从广义的 devops 来讲,容器云平台的租户模式和标准中间件交付能力,都是 devops 落地过程中起到积极作用的。因此,窃以为容器云平台和 devops 平台应该在面向能力交付的维度进行深度融合。

【 A4 】 acbogeh 系统工程师 , 富国基金

容器的特性决定了其天然的就是满足 devops 精神的,更容易 cicd 。

【 Q2 】容器云平台与虚拟机平台 devops 工具兼容问题?

对于很多公司而言,在使用容器云平台之前,都有自己的一套基于虚拟机的 devops 流水线平台,那么在使用容器云平台以后,如何在 devops 流水线平台上同时兼容基于容器和虚拟机的 devops 流程?

【 A1 】 jiangjf2DevOps 工程师 , 安信证券

我理解这里主要的差异在构建节点和工具层面,对于流水线过程来说,只是在部署环节的实现不同。也就是整条流水线的其中一个 stage 的实现不同,对流水线过程来说不一定存在差异。部署过程流水线提供的是发布到虚拟机和容器云平台的能力,比如我们在虚拟机的部署方面是通过 ansible 来进行的,容器云平台的部署则是通过 Kubectl 命令行工具管理 Kubernetes 集群。应用部署逻辑则是由项目团队提供 playbook 或 yaml 文件,设置环境信息:对于虚拟机来说是 ip ,对于容器来说是 namespace 。也就是平台提供两种部署方式的能力,项目团队只需要关注自己需要哪种部署方式,以及流水线在什么时间需要执行部署任务。在后续的建设中我们计划通过统一的发布平台来提供应用部署到虚拟机和容器云平台的支持,流水线基于统一的发布平台完成部署过程,进一步减小用户对两种部署方式差异的感知。

【 A2 】匿名用户

我们建议将容器平台作为基础设施,然后再容器和 IaaS 平台之上建设一个统一的应用发布平台。最后 CICD 流水线的最后一步与这个应用发布平台对接。这样在开发测试阶段,可以实现兼容容器和虚拟机的应用发布,在生产环境也可以实现容器 / 虚拟机应用的统一发布管理

【 Q3 】生产环境下的容器云平台安全管理是如何考虑的,怎样更好地做好 DevSecOps ?

容器应用到生产环境之后相对于传统架构,会面临更多安全问题,请问安全管理这方面是如何考虑的?
另外,有没有 DevSecOps 方面的实践可以分享的?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

平台安全主要有两个方面: 1 、产品安全。 2 、给用户建立正确的安全使用理念

https://www.stackrox.com/kubernetes-adoption-security-and-market-share-for-containers/

根据最新发布的《 Kubernetes 和容器安全状况报告》表明在过去的 12 个月里,有 94 % 的组织在其容器环境中遇到过安全问题,其中 69 % 的组织检测到错误配置, 27 % 的组织在运行时遇到安全事件,还有 24 % 的组织发现了严重的安全漏洞。

Kubernetes 安全风险和挑战

外部访问攻击:核心组件非安全端口对外暴露,以及连接集群关键凭证泄漏。

平台组件攻击: 利用平台组件 docker 、 kube-apiserver 、 etcd 、 kubelet 非安全端口对外暴露,以及集群组件间连接安全,以及组件的安全漏洞进行攻击。

POD 层面攻击:利用运行在集群内的恶意 POD 进行攻击,需要对 POD 权限进行安全限制

非安全镜像攻击:容器的主要来源于容器镜像,研究表明 Dockerhub 上百分之 76 的镜像存在安全漏洞:滥用镜像和镜像注册中心会带来安全问题导致被黑客利用镜像安全漏洞进行攻击。

请求控制:现有容器云平台通过 RBAC 方式对只能对用户权限进行限制,无法对用户发送的请求进行合规性鉴别和限制,需要引入请求控制器,对用户对集群操作的请求进行限制。

一些我们给一些金融客户的安全建议

平台层面

1 、使用 pod security policy 限制 POD 的一些行为

2 、定期使用 rancher 集成 CIS 扫描(现已能实现自动扫描)

互联网安全中心( CIS )发布的全面的 Kubernetes Benchmark 建立 Kubernetes 的安全配置规范

( 1 )集群组件配置检查( Api-server 、 controller-manager 、 scheduler 、 etcd )是否符合安全配置参数。

( 2 )集群组件配置文件权限检查。

( 3 )策略检查( pod 安全策略、网络安全策略检查)。

3 、使用 OPA 进行请求策略控制。

4 、使用 POD 安全策略进行限制,目前 rancher 内可以配置项目间网络隔离。

镜像层面

1 、定期进行镜像安全漏洞扫描、定期更新漏洞库

2 、设置镜像安全下载策略如超过 3 个高危漏洞,就禁止下载。

3 、最小镜像原则,使用体积小的 base 镜像降低攻击面

Google 发布的 Distroless 镜像仅包含应用程序及其运行时依赖项。不包含程序包管理器, shell 和在标准 Linux 发行版中找到的任何其他程序。

Distroless 提供 java 、 python 、 Nodejs 、 dotnet 等开发语言的基础镜像

优点:

1 、降低镜像体积、减少磁盘空间占用。

2 、只安装应用所依赖的组件,无其他组件降低攻击面。

缺点:

1 、没有 shell 和一些调试工具,出故障时无法方便调试,但可以通过临时容器进行调试

应用层面

基础镜像规范化避免乱使用

镜像内使用非特权用户

镜像漏洞扫描,定义风险阈值

代码安全

通过 TLS 访问,对传输内容加密

限制通信端口范围

确保第三方依赖安全性

静态代码分析

动态探测攻击

三、容器云与微服务

【 Q1 】微服务体系与容器云如何融合?

微服务体系有自己的治理与度量监控体系,容器云也有 k8s 的编排与部署。在真实生产环境下,容器云的编排可以取代传统的微服务治理体系吗?是替代关系还是融合关系?如何实践

【 A1 】 mtming333 系统运维工程师 , 甜橙金融翼支付

在真实生产环境下,替代和融合都困难,有一定开发改造量,而在平台之上独立部署微服务架构较好。当然也有尝试做融合的,看到鹅厂有投入精力做注册中心同步。

【 Q2 】如何实现有状态服务落地,例如数据库一主一从、一主多从、多主多从,读写分离?

如何实现有状态服务落地,例如数据库一主一从、一主多从、多主多从,读写分离?

【 A1 】 gxcornflakes 信息技术经理 , 某金融单位

数据库建议虚拟机或者物理机部署。
容器部署数据库,也许开发测试环境玩一玩。生产环境还是不建议使用容器部署,加深运维难度,得不偿失,不求先进性,但求稳定性。

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

可以试试 mysql-operator https://github.com/presslabs/mysql-operator

【 Q3 】容器中的东西向流量如何管理和隔离,以便防止异常的访问出现?

【 A1 】 wykkx 系统架构师 , 某基金公司

api 网关,流量管理,鉴权,降级,限流,都可以做。

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

可以通过 NetworkPolicy 实现东西向流量隔离,但 NetworkPolicy 无法实现更高级的管理;

可以通过 Cilium 实现透明安全策略与流量可视化、流量重定向等更高级的应用;

可以通过 Istio 等服务网格技术实现流量劫持、流量路由等服务治理能力。

这些都是 Rancher 集群中集成的能力

【 Q4 】容器云上服务治理问题?

企业应用微服务上容器云原则、标准等。新应用应如何去按照微服务体系设计架构,容器云上服务治理等问题?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

微服务上容器原则、标准,微服务设计,服务治理,这是一个非常大的话题,非三言两语能说清。

建议了解一下云原生应用模型与定义、十二因素应用、微服务治理架构、架构演进、模块化、服务网格等知识。

四、容器云与监控

【 Q1 】容器环境的微服务如何进行链路可视化,通过 APM 工具的话哪些比较适合容器环境使用?

【 A1 】 wykkx 系统架构师 , 某基金公司

链路可视化如果是基于进程级别的,其实不是特别在意是容器环境还是虚拟机环境,都是向下屏蔽的。如果预算有限,建议使用开源的 skywalking 方案,该方案无入侵,功能强大,社区活跃,建议使用。

【 A2 】 jiangjf2DevOps 工程师 , 安信证券

如果引入服务网格如 istio ,则通过 jaeger 支持的比较好,服务网格的代理 envoy ,会自动生成 traceID ,可以由 jaeger 收集起来,形成调用链,类似的还有 skywalking ,也在和 envoy 对接中。

如果不引入服务网格,则需要应用对接 skywalking , jaeger ,即在应用进程内启动一个 agent ,对链路数据收集后发送到 server 端处理。

【 A3 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

目前容器环境下的微服务监控方案也比较成熟,可选择性也比较多,像商业的 Dynatrace 就能够很好的的实现从底层到应用层的全景监控,开源的方案目前比较主流的有 Pinpoint 、 Skywalking 、 Istio 等,其中 Pinpoint 和 Skywalking 主要采用 Java 语言开发,对 Java 生态有着非常好的支持,启动时通过 Java agent 的方式就可以快速集成,对于其他语言社区也提供了一些集成方案, Istio 这种就是目前主流的服务网格的方案,与语言无关,通过 sidecar 的方式集成,也可以实现微服务链路可视化。

ps : rancher 已经集群 istio ,可以直接在 UI 上查看应用关系调用。

【 Q2 】容器云平台故障排查?

容器云平台的使用方式和传统的物理机以及虚拟机都有较大的差距,那么在生产系统使用容器云平台部署应用以后,如果出现生产问题,应该如何快速定位和解决问题,需要开发人员和运维人员具备什么样的技能?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

建议选择专业的容器云厂商提供专业的服务

以下为我司技术专家总结的一些经验

  1. 建议您在使用测试环境时或者是上线生产前就应当建立一个相对完善的生产环境问题应急处理办法和标准,以应对生产环境中的紧急问题情况处理。
  2. 关于如何快速定位和解决问题,有点些太过宽泛。但是快速解决问题的基础是首先要对整个平台的架构和各组件的功能交互非常熟悉和有最基本的运维思路。最起码要判断这个问题是 docker 层面的, k8s 层面的还是平台层面的。在深入去看具体组件或者资源的问题,看日志看现象看资源使用。
  3. 开发人员和运维人员需要具备容器知识, docker 和 k8s 的使用和运维经验 ( 包含组件交互原理,网络,存储,资源分配,监控,日志等 ) 。

排查问题的思路:

观察问题:细致的观察问题发生时的情况,做好对问题的描述和记录

收集信息:尽可能的去收集问题发生时的日志信息。比如说平台日志,容器日志,应用日志。还有环境信息,内核版本, docker 版本, k8s 版本,网络模式等。

复现问题:接下来根据收集到的信息,清楚复现问题的步骤,并记录。

收缩范围:排查无关的因素和影响,缩小范围。

定位问题:把产生问题的可能原因定位在一个或几个上。这样可以通过控制变量去进一步排除问题的可能。

解决方案:根据这些问题可能会出现的原因,去指定一个解决方案。

执行方案,解决问题:要做好记录,要预留足够的时间避免新的问题的产生。

解决问题的思路:

是否需要做应急策略

考虑是否可以复现问题,如果可以复现的话记录并观察这个复现的过程,有可能在复现过程中,就可以直接定位问题发生的原因。

如果故障是偶发性的,是有极小概率出现的,就比较难排查,这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位原因。

复现后,通过已掌握的技术知识和经验基本可以确定问题产生的原因,列举出来。

考虑一下这些问题产生的原因是不是有优先级的关系,先去解决可能性大的原因。提升效率。

接下来逐一对这些问题产生的原因进行排查,并对每一个排查的过程做记录

如果超出所考虑的这些原因,那么需要重新回头再去看问题如何解决。

应急恢复的方法:

首先还是要保证系统的可用性

服务整体性能下降或异常,可以考虑重启服务;

应用做过变更,可以考虑是否需要回切变更;

资源不足,可以考虑应急扩容;

应用性能问题,可以考虑调整应用参数、日志参数;

系统漏洞问题,是否考虑升级版本

【 A2 】 acbogeh 系统工程师 , 富国基金

1.k8s 的命令得熟,有些问题还是得进容器看

  1. 日志统一收集,用统一的日志平台来看日志比较方便
    3.skywalking 等工具来完成链路的调用监控,找到问题所在。

【 Q3 】现有监控系统如何和容器云平台监控对接和融合?

1 、容器云平台监控技术用什么?会覆盖哪些监控,比如主机 / 容器资源监控、容器平台组件监控、容器内部中间件 / 业务监控?
2 、现有监控系统技术用什么?
3 、容器云平台监控怎么和现有监控系统对接,哪些维度数据会对接,如监控数据、告警数据?现有监控会展示容器云哪些监控数据?

【 A1 】 acbogeh 系统工程师 , 富国基金

zabbix/promethus 两条路线,前者相对还是适合传统基建告警;后者偏向容器
但是一般企业希望统一告警,那目前可以用 zabbix 对接 promethus 的 alert export 来实现告警统一收集统一发送。

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

容器云平台监控和容器应用监控主要使用 Prometheus ,告警可以通过 Altermanager webhook 方式对接自己外部的统一告警系统, rancher 已经内置了 Prometheus 监控包含多个层面监控包括:集群层面资源使用监控和组件性能监控、节点资源监控、容器应用资源监控。对于一些需要针对业务的监控可以使用自定义监控方式实现对业务指标监控。

针对多集群的监控, rancher 内集成了统一监控展示,将多个集群中的 top 信息进行统一展示如 : 最消耗 cpu 、 memory 的 pod top10

一般情况下,与现有监控系统都是在监控指标展示层面进行对接,将数据通过统一的大屏进行展示。

五、其他

【 Q1 】容器云平台是否能很好的支持 IPv6 ?

目前金融行业正在进行 IPv6 的推广阶段,不少应用已迁移至 IPv6 环境,且有些应用不能使用 64 转换,在这种情况下,容器云是否已能完全支持 IPv6

【 A1 】 gxcornflakes 信息技术经理 , 某金融单位

目前 Kubernetes 社区对于 IPv6 支持的进展如下: 从 Kubernetes 1.9 版本开始,添加了对于 IPv6 的集群的支持,作为 alpha 功能 ; 从 1.13 版本开始, Kubernetes 默认 DNS 服务器更改为具有完全 IPv6 支持的 CoreDNS ; 从 1.16 版本开始,提供了对于 IPv4/IPv6 双栈支持,如果 Kubernetes 集群启用了 IPv4 / IPv6 双协议栈网络,则该集群将支持同时分配 IPv4 和 IPv6 地址。 因此基于 Kubernetes 的容器云平台选型 1.16+ 版本。
在 Kubernetes 集群上启用 IPv4/IPv6 双栈协议可提供以下功能:

  • 双栈 Pod 网络(每个 Pod 分配一个 IPv4 和 IPv6 地址)

支持 IPv4 和 IPv6 的服务(每个服务必须用于单个地址系列 ) - 同时通过 IPv4 和 IPv6 接口的集群外出口路由(例如 Internet ) 为了利用 IPv4 / IPv6 双栈 Kubernetes 集群,需要满足以下先决条件: - Kubernetes 1.16 或更高版本

提供程序对双栈网络的支持(云提供程序或其他方式必须能够为 Kubernetes 节点提供可路由的 IPv4 / IPv6 网络接口)

支持双栈的网络插件 CNI (例如 Kubenet 、 Calico 、 Canel )

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

楼上同学有个地方答错了,目前社区内应该就 calico 对双栈 ip 支持比较好, flannel 和 canal 是不支持的 issue 如下: https://github.com/etcd-io/etcd/blob/master/Documentation/tuning.md
因为 Rancher 在金融中有非常多客户,所以在网络插件这块 rancher 的 canal+macvlan 支持对 pod 同时分配 ipv4 和 ipv6 ip 地址,满足金融监管要求

【 A3 】 duanzhanling 软件开发工程师 , 段占领

这个要根据实际情况进行处理

  1. 如果是自建 IDC 的话,相关的防火墙或者路由器需要支持 IPv6 ,同时 k8s 的 ingress 也要启用 ipv6 功能
  2. 如果是使用阿里云的 ACK 的话, svc 创建 slb , slb 是支持 ipv6 的。

【 Q2 】关于 SUSE 收购 Rancher 后将要面临的问题?

我们都知道 SUSE 收购了 Rancher ,这也说明 Rancher 无论技术实力还是发展方向都得到了认可,在此之后, Rancher 今后产品发展路线是怎么样的?是否能够继续走国产化路线?能否独立运营?未来的企业服务和技术支持将会由谁来提供?

【 A1 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

Rancher 今后产品发展路线是怎样的?

Rancher 系列产品将持续创新与发展,这是 SUSE 公司 “ 创新无处不在 ” 理念的重要支撑。凭借我们面向开源软件的强大模块化策略,为客户提供可靠且灵活的容器 /Kubernetes 云原生产品及解决方案,无论是在数据中心、云端还是边缘环境。原 Rancher CEO 及联合创始人梁胜博士已出任 SUSE 的工程与创新总裁,将 · 负责技术方向和产品研发的全把控。

是否能继续走国产化路线?

会。立足中国、服务中国的理念是 SUSE 管理团队高度认可并将持续执行的,我们的国产化路线将在未来一如既往地坚定进行。我们将在国产化资质及生态建设方面持续投入,在软件著作权、国内各类资质认证、与国产厂商的兼容性认证等各方各面继续发力。

能否独立运营?

Rancher 中国将作为 SUSE 中国的一部分在中国市场运营,为中国客户服务。 Rancher 全系列产品都将作为 SUSE 产品的一部分继续销售。但是 Rancher 品牌并不会因为此次收购而消失。 Rancher 先进的云原生技术能力、创新的产品理念、优异的用户口碑、在 Kubernetes 管理领域的领导者地位,均为 SUSE 所高度认可和需要。未来, Rancher 产品的研发团队将得到更大的投资力度,拥有更大的规模, Rancher 中国企业版产品及 Rancher 中国软件定义边缘计算平台产品将继续得到更多功能增强和更好的服务支持体验。

未来的企业服务和技术支持将会由谁来提供?

Rancher 的技术支持团队将成为 SUSE 技术支持团队的一部分,一如既往地为客户提供世界一流的企业服务和技术支持。同时,因为 SUSE 是一个发展更成熟、规模更大的公司,技术支持的团队的规模和力量将因此次收购进一步加强,更大的团队规模、更多的人员力量、更完备的技术栈,将让我们对中国企业客户的服务支持承诺得到更大程度和范围的提升及保障。

【 Q3 】关于生产使用容器云的时点?

请问在微服务数量较少( 20 左右)的情况下,适合上 k8s 等容器云技术吗?会不会效果不是特别明显却对运维人员造成额外的压力?有很多证券公司生产用了微服务但是没上容器云,请问上容器云的最佳时点是什么,会对运维、研发带来明显的收益?毕竟人员学习是有成本的

【 A1 】 wykkx 系统架构师 , 某基金公司

首先要澄清一个问题,就是微服务不代表一定要使用容器,哪怕是微服务的数量多了也未必要使用容器云,只是说容器云的特性比较便于微服务的落地。支付宝在 2018 年前有大量微服务,但是也没有都容器化,还是部署在虚拟机。使用容器云,对开发和运维人员的技术栈肯定是有新的要求的,会增加学习成本。在笔者看来,还是要根据实际的业务需要,如果出现了确实需要容器云平台的场景,再考虑上生产,在此之前可以开发测试环境进行测试验证,积累经验。

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

容器根微服务并不是强关联的,只是说微服务应用结合容器,带来了快速与可移植性。从开发、测试、上线,实现了 “ 一次编写,到处运行 ” 。另外从我今年部署和实施的金融客户看,现在做容器云正是最好的时机。

1 、 Kubernetes 日渐成熟。 2 、开源社区和市面上关于容器的接纳度也逐渐提高这个对应的就是我也发现现在越来越多的软件供应商都把自己产品做成容器云部署方式。 3 、现在在金融行业、证券、银行、保险其实有大量的落地案例可参考

对运维和开发人员的收益

1 、轻量级:相比与传统虚拟机的方式,容器确实轻很多,容器的启动是毫秒级的,而且对性能损耗比 较小。

2 、版本控制:通过镜像版本直接控制应用的版本,升级和降级。

3 、推动了应用微服务化:将每个微服务组件封装成一个容器镜像,直接通过这个镜像部署应用。

4 、标准化交付:由文档 + 安装包式的软件交付,到容器镜像的交付。

5 、跨环境运行:容器可以在主流 Linux, Windows, MacOS 上运行。

6 、提高工作效率:让研发更专注业务开发,运维更专注在业务维护, 极大的减少部署的时间成本和人力成本。

最后容器平台建设包括几个大方面:平台建设、容器周边生态建设( cicd 、日志、监控、 Devops )、应用上云 对于大部分公司自建容器云要走很多弯路,我一般建议用户选择市面上比较成熟的产品和公司来协助建设,这样可以大大降低用户自建的使用成本,前期可以先尝试使用一些开源的容器云平台如 Rancher ,非常简单易用

【 Q4 】容器云环境如何与公司现有的 CMDB 融合,哪些 CI 适合纳入 CMDB 管理,并被外界哪些系统去消费?

【 A1 】 wykkx 系统架构师 , 某基金公司

目前我司是采集了容器云的 service 和 pod 信息,以及 CI/CD 信息注入到 CMDB 平台中,并且归属到相应的应用下。目前的消费场景是在做自动化变更的时候,可以基于 CMDB 中的信息,在变更工单中选择容器平台需要执行的流水线,进行变更操作。

【 A2 】 wanshaoyuanit 技术咨询顾问 , Rancher 企业级 Kubernetes 管理平台

楼上已经说的很详细了,我这里简单提一下我们之前一些客户的使用方式,将 POD 和对应控制器信息收集并在容器云平台上展示,将 POD 和虚拟机关联关系进行展示。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

相关文章

相关问题

相关资料

X社区推广