edwin1986
作者edwin19862018-10-29 10:45
系统架构师, 上汽通用汽车

汽车制造行业容器云平台设计与实践难点问题

字数 4493阅读 5296评论 1赞 4

一. 前言

虚拟化技术作为云计算的前提之一,不断伴随引发着深远的技术变更。早期的虚拟机虚拟化,将传统物理计算资源虚拟化为若干虚拟服务器,可各自运行各自的操作系统,从而提高整体计算资源利用率。但随着业务敏捷需求逐步显现,业务服务颗粒度不断变小,微服务架构便随之产生。微服务架构的细颗粒度隔离需求和管理需求使得容器技术逐渐成为对云计算领域具有深远影响的变革技术。容器技术的发展和应用,将为各行业应用云计算提供了新思路,同时容器技术也将对云计算的交付方式、效率、PaaS平台的构建等方面产生深远的影响,具体体现在以下几个方面:

  1. 部署:容器可以将应用打包成单一可运行、可储存的组件,并且在任何时间任何地点进行部署。
  2. 启动:容器共享宿主机操作系统kernel,使得容器中的进程启动和在操作系统中类似,不必像虚拟机一样额外启动操作系统,故启动速度将变快。
  3. 组装:容器的细颗粒度和轻量化实现导致运行在容器中的应用可以轻易进行服务组合和再封装。
  4. 迁移透明:容器技术最重要的价值就是为在不同宿主机上运行服务提供一个轻便的、一致的格式。容器的标准化和CNCF等组织的成立,使得相关技术逐步标准化和透明化,避免局限于单一的平台提供商。

随着某司业务的进一步发展,为成为国内领先世界一流的汽车制造企业,汽车业务服务需要进一步拓展。为了更加快捷有效地为业务服务提供IT支撑,为了更加敏捷便利地应对业务高峰,为了更加快速高效地IT开发交付,某司启动了容器云平台项目,构建跨数据中心统一容器云平台。通过该平台的搭建,改善了IT的项目交付模式,将传统以虚拟机加应用的交付模式,以容器镜像进行交付。同时统一管理容器实例,以更好应对业务变化,并提升IT基础硬件资源利用率。
为了让各位汽车同行朋友了解车企容器云平台设计与实践过程,twt社区特别组织了本次线上的答疑活动,邀请某汽车主机厂容器云项目负责人作为答疑嘉宾。欢迎大家阅读专家撰写的最佳实践文章,提出相关的问题,和专家在线交流。活动中,大家踊跃发言和积极答疑,提出了许多真知灼见。为了更好、更方便的让大家了解到本次交流活动的干货,更好地进行PaaS项目建设,在此我将本次活动的问题和解答进行了总结,如有不妥之处,还请谅解。

二. 汽车制造行业容器云平台设计与实践在线答疑

Q:容器云和虚拟化哪个效率高?
A:容器的效率会高,这里的高指的是性能损耗方面。容器的image只是个rootfs,包括操作系统的整个运行环境,内核使用的还是宿主机的。同一宿主机下不管多少容器都得共享使用宿主机的内核,所以如果部分容器需要配置特殊的内核参数,做出的修改是全局的,这也是容器技术当下的一个特点,是优点也是缺点。传统的虚拟化技术没有这个问题。
早期做过个实验,同样性能的服务器虚拟化性能损失基本在20%左右,而容器化几乎没有性能损失。具体可以通过sysbench进行测试。容器可通过docker run -it --rm dotnetdr/sysbench:0.5 sysbench --test=cpu --cpu-max-prime=2000 run进行测试

Q:容器云优点是什么?
A:弹性、轻量、快速部署、自动扩容和自愈

Q: 为什么docker热了?你觉得主要是与哪些因素有关?
A:cgroup和namespace是linux kernel的特征 ,过去使用起来很复杂,结果docker一个命令就可以搞定这些事情,从而使得用起来很方便。在虚拟化技术发展的过程中,比如一个物理机有10个虚拟机,每个虚拟机安装的操作系统会有大量的操作系统进程用于调度进程和管理硬件资源等,假设有20个操作系统进程,而实践经验中可能每个操作系统只部署一个web应用进程,从物理机角度看,这样上面的实际进程是 10个web进程/(10个虚拟机*20个操作系统进程)=1/20。
如果采用容器技术,那么在一个操作系统上面可以运行10个web进程,这样的实际进程是10个web进程/20个的操作进程=1/2。这样看来,更多的物理资源用来运行web进程,而多个进程可以共享一套操作系统的管理进程组,从而提升资源利用率。
Docker与传统容器比起来,有如下改善:

  • 集装箱:黑盒运行模式,使得Build once, Run “anywhere”。(这点依赖于os kernel以及cpu:比如x86和arm,所以我打引号)但比起传统PaaS的环境差异性,是有极大改善的。
  • 轻量和弹性:镜像层解构的创新,使得下层镜像“共享”方便传播和部署。
  • 生态:CNCF

Q: 为什么kubernetes会出现pod这个抽象?
A:pod是基于容器更高层度的抽象,主要提供多容器的package运行。其核心实现了类似容器操作系统的抽象,使得可以在不侵入pod中容器的前提下对其进行底层控制,实现包括Sidecar、Ambassador或Adapter相关的模式。
从设计角度,一方面,如果每个容器都占用一个IP stack等资源,那么操作系统资源耗费会比较多。另一方面,多个容器之间可能存在一个逻辑上的相关管理,比如一个pod里面可以有一个web容器,一个mysql容器,web和mysql是互相关联的,如果放在一个pod中,二者可以共享一个IP stack。
具体参考https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/https://kubernetes.io/blog/2016/06/container-design-patterns/

Q: 容器应用的监控方案如何设计?
A: 两个关键词:

  1. sidecar
  2. https://prometheus.io/

Q: 应用向容器云迁移时有哪些技术障碍需要克服?有哪些风险需要预防?
A: 开发成熟度:应用耦合情况。我觉得微服务不是必须,但无状态服务是很大的前提。
人员成熟度:面对巨大的学习曲线是否有能力快速掌握
技术堆栈:传统和容器化的技术堆栈存在一定差异,如何共存?而不是简单建两套使得TCO剧增。

Q:企业容器云的构建思路和步骤?
A:首先需要确认做容器的初衷是什么,分析哪类业务需要容器化?
人员和组织定义:哪类人实施,开发团队准备好了么,运维团队准备好了么
技术堆栈选型:涉及哪类容器平台docker/k8s等,配套设施做哪些
实施方式定义:包括自建、外部partner等

Q: 贵公司都是用的容器来部署微服务吗? 能问下你们的容器架构是演化出来的,还是顶层设计出来的?
A:看业务受众:如果是面向企业,由于业务链路长,建议从顶层往下解构,到level3之后再考虑服务化(而不是微服务化),这个和成熟度有关。
如果业务面向C或业务链路短,可以考虑通过下层快速迭代演进。

Q: 贵企建设容器云平台,人员配置方面是怎样的?
A: 独立构建,涉及基础平台和上层服务。前者短期手工运维,但通过开发逐步自动化。后者通过开发实现。支撑人员和运营容器数量关系不大,但和上层开发服务的数量正相关。关键点:开发从上往下做。

Q: 容器云平台的安全问题是如何保证的?
A: 需要考虑多个层次,主要包括:
容器主机:主机本身的安全设置、SELinux的启用、Cgroups和Namespaces使用等
容器镜像:基础镜像使用、基础镜像更新和漏洞扫描等
容器仓库:通过建立TLS仓库,并通过HTTPS绑定,这样Docker只能从授信的仓库获取镜像
容器构建和部署:与正常CI/CD类似,但需要规避业务应用使用特权容器运行的情况
容器平台:平台解决方案实现

Q: 上容器之后会带来哪些方面的挑战呢?
A: 第一个:人。kubernetes学习曲线比起原生docker高很多,如何掌握学习脉络?第二个:组织。传统稳态组织和敏态组织的演化和融汇。第三个:文化。如何良性互动?

Q: 企业容器云的性价比高吗?
A: 需要考虑下使用容器的初衷,究竟是业务的敏捷弹性需求触发呢还是交付复杂性需求初衷
同时需要注意:
资源利用率提升导致费用的节省、固定资产投资费用前后差异、人员学习成本及能力依赖差异、开源文化收益

Q: openshift启动报错问题?openshift 启动老是报错 请专家看看是什么问题?
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --cgroup-driver=cgroupfs"
openshift 启动老是报错
F1023 23:31:53.473817 3955 node.go:264] failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
hhey5n978nes

hhey5n978nes

A: kubelet 默认的 cGroup 为 cgroupfs 而 docker 默认的 cGroup 为 systemd
需要在下列文件添加:
vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
rg7dnn3acz4v
rg7dnn3acz4v

qawzezab14xu
qawzezab14xu

具体可参考https://github.com/kubernetes/kubernetes/issues/66747

Q: 容器云的建设规划与方案设计需要遵循什么原则?
A: 满足不同形态业务用户需求。敏态:无状态容器化方案。稳态:有状态持久化方案。业务可用性。满足组织可用性需求。比如多活等。原则上整体可用性应不低于传统方案。当然由于容器的特性,需要架构和上层建筑保证。系统管理。满足原先组织监管相关需求。但需要平衡传统模式和新模式(类似devops)的差异,需要考虑在这过程中ITIL等流程如何更自动化智能化满足需求。

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

4

添加新评论1 条评论

wuwenpinwuwenpin软件开发工程师, 南京
2018-10-29 17:36
有用的资料。。
Ctrl+Enter 发表

本文隶属于专栏

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

作者其他文章

相关文章

相关问题

相关资料

X社区推广