【大话IT】工业互联网云平台架构设计之容器技术解析

renfengjun · 发表于 2019-8-22 16:45

本帖最后由 renfengjun 于 2019-9-10 10:16 编辑

公司内部一直使用的是自研的一套框架加上puppet 和 ansible tower 完成公司内部app 以及 db server的管理以及申请工作。有部分应用在aws，但是由于成本问题，aws上的应用不是很广泛。
也有一些团队在测试docker 以及kubernates 在云上的使用，如果能够降低使用成本公司应该会很愿意增加公有云的使用。
但是如果说使用docker 和kubernates 替换内部的现有自动化部署基础架构，感觉还不是很现实，因为公司内部使用的大多数还是一些开源技术，ansible tower 也只是使用了一小部分而已。

个人使用docker部署过一些数据库相关的应用，感觉还是很方便的。
但是对于公司来讲主要还是成本控制问题。所以至少对于公司现状，还没有替换的打算。

/roll = 100
需要一个书包，需要一个“年”

sap配牛奶 · 发表于 2019-8-22 17:05

占位学习

youyouky · 发表于 2019-8-22 19:36

话题讨论：
1、打造工业互联网云平台架构，您认为哪些环节非常关键？
需求环节：需求环节需要根据自身需要制定合理的业务需求，业务需求要考虑公司中长期发展目标，必须和公司发展方向保持一致，否则很容易导致需求梳理不完善，无法满足后期发展需求；需求制定好高骛远，脱离实际，导致无法和公司发展好好配合，还浪费资源。
技术环节：技术环节首先要考虑技术架构，目前云技术发展很快，需要根据自身需求和发展需要制定合理的中长期发展计划。有了业务需求和发展目前，才能制定出合理的技术方案和架构，然后规划处IT投入，包括硬件、软件和人员投入，以及后期的技术储备等。
管理环节：其实信息环节主要是把“互联网云平台”理解成一个共享、互助的互联网平台，在这个平台上自身能获取哪些有价值的信息，又能为平台贡献多少有用的信息。考虑到信息对各公司的重要性和保密性，所以，即便平台搭建好了。平台的安全性、运行稳定性、数据保密性谁来保障？
领导环节：任何改变现状的技术变革或更新，都会触及一部分人员的既得利益，会遇到很多人为阻力。所以这种项目必须有大领导的鼎力支持，否则项目推进过程中会阻力重重。

2、有人说容器是云原生应用的集大成者，您如何看待容器和云原生之间的关系？
“云原生”是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，和位置无关。这意味着应用程序位于云中，而不是传统数据中心。意味着使用开源软件堆栈进行容器化，其中应用程序的每个部分都打包在自己的容器中，动态编排，以便每个部分都被主动调度和管理，以优化资源利用率和面向微服务的应用程序，以提高应用程序的整体灵活性和可维护性。
对于云原生应用程序而言，最大的不同之处在于应用程序的构建，交付和运维方式。“利用云服务意味着使用敏捷和可扩展的组件（如容器）来提供离散和可重用的功能，这些功能以良好描述的方式集成，甚至跨越多云等技术边界，这使得交付团队可以使用可重复的自动化和编排来快速迭代。”
云原生应用程序开发通常包括DevOps，敏捷方法，微服务，云平台，Kubernetes和Docker等容器，以及持续交付，简而言之，每种新的和现代的应用程序部署方法。

3、您如何看待Kubernetes、Swarm、Rancher、Mesos、ECS等这些容器编排解决方案带来的价值？
典型的容器编排工具有助于虚拟化一组机器并将它们作为单个集群管理。容器编排工具也有助于将机器上的工作负载或容器移动到消费者透明的位置。很多工具目前既支持基于Docker的容器，也支持非容器化二进制文件部署，例如独立的Spring Boot应用程序。这些容器编排工具的基本功能是从应用程序中抽象出实际的服务器实例。
容器编排工具的一些关键能力概括如下：
集群管理：将虚拟机和物理机器的集群管理为一台大型机器。这些机器在资源能力方面可能有些差异，但大体上都是以Linux作为操作系统的机器。这些虚拟集群可以建立在云上、本地或两者的混合。
部署：能处理有大量机器的应用程序和容器的自动部署。支持多个版本的应用程序容器，并且还支持跨越大量集群机器的滚动升级。这些工具还能够处理故障回滚。
可伸缩性：支持应用实例的自动和手动伸缩，以性能优化为主要目标。
健康：它管理集群、节点和应用程序的健康。可以从集群中移除异常的机器和应用程序实例。
基础结构抽象化：开发人员不必担心机器、容量等问题。完全是容器编排工具来决定如何调度和运行应用程序。这些工具也抽象化机器的细节、能力、使用和位置。对于应用程序所有者来说，它们相当于一个容量几乎无限的大型机器。
资源优化：这些工具以有效的方式在一组可用机器上分配容器工作负载，从而降低成本，通过从简单的到复杂的算法可有效地提高利用率。
资源分配：基于应用程序开发人员设置的资源可用性和约束来分配服务器。资源分配将基于约束、规则、端口要求、应用依赖性、健康等等。
服务可用性：确保服务在集群中正常运行。在机器故障的情况下，容器编排会自动通过在集群中的其他机器上重新启动这些服务来处理故障。
敏捷性：敏捷性工具能够快速分配工作负载到可用资源，或者在资源需求发生变化时跨机器移动工作量。此外，可以根据业务临界性、业务优先级等来设置约束重新调整资源。
隔离：一些工具提供了资源隔离。因此，即使应用程序不是容器化的，也可以实现资源隔离。

4、从传统IT架构到K8S，您会做哪些准备，考量哪些要素？
从传统IT架构到K8S，主要是应用微服务架构改造，传统应用架构并不适用容器部署，只有做微服务改造后的应用，才适用新的部署方式。
另外，新的IT架构，给运维工作也带来了新的挑战。需要具备更多的容器知识和运维思维方式的转变，之前不可能做到的事情，通过容器就可以很方便的实现，如短时间内大批量新增/回收应用节点。

5、如何解决K8S的集群管理、智能负载均衡等问题？
k8s是一个完备的分布式系统支持平台，k8s具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级能力和在线扩容能力、可扩展的资源自我调度机制，以及粒度度的资源配额管理能力。同时k8s提供了完善的管理工具。这些工具包含开发，部署测试，运维监控在内的各个环节，因此，k8s是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式完备的分布式系统开发和支撑平台。
Kubernetes关于服务的暴露主要是通过NodePort方式，通过绑定minion主机的某个端口,然后进行pod的请求转发和负载均衡，但这种方式下缺陷是
Service可能有很多个，如果每个都绑定一个node主机端口的话，主机需要开放外围一堆的端口进行服务调用，管理混乱
无法应用很多公司要求的防火墙规则.
理想的方式是通过一个外部的负载均衡器，绑定固定的端口，比如80,然后根据域名或者服务名向后面的Service ip转发,Nginx很好的解决了这个需求，但问题是如果有新的服务加入，如何去修改Nginx的配置，并且加载这些配置？ Kubernetes给出的方案就是Ingress,Ingress包含了两大主件Ingress Controller和Ingress.
Ingress解决的是新的服务加入后，域名和服务的对应问题，基本上是一个ingress的对象，通过yaml进行创建和更新进行加载。
Ingress Controller是将Ingress这种变化生成一段Nginx的配置，然后将这个配置通过Kubernetes API写到Nginx的Pod中，然后reload.

6、关于跨云的资源管理与调度问题，您有哪些实战经验？
资源调度是指在特定的资源环境下，根据一定的资源使用规则，在不同的资源使用者之间进行资源调整的过程。这些资源使用者对应着不同的计算任务(例如一个虚拟解决方案)，每个计算任务存操作系统中对应于一个或者多个进程。通常有两种途径可以实现计算任务的资源调度:在计算任务所在的机器上调整分配给它的资源使用量，或者将计算任务转移到其他机器上。
云资源调度问题主要分为三层：为应用程序调度资源，调度虚拟资源（如虚拟机）到物理资源，物理资源调度和落地。而且，在每一层可以有多个不同的目标进行优化。在应用层，可能要满足用户指定的服务水平目标（SLO） - 即调度QoS，优化提供商的效率，或者在两者之间协商一些妥协。在虚拟资源层，可以优化负载均衡，提高资源利用率例如CPU和内存的占比，此外还有成本效益或节能。

7、您所在企业在容器以及云平台建设中有哪些新的规划和目标？（可选回答）
边观察边实践，参考同行业案例。现在非核心的边缘业务尝试试用，核心业务暂时很迁到到容器以及云平台架构。