既然是有状态的应用,因为容器灵活迁移的特点,建议容器应用最好是把状态数据写到外部的存储中,可以是共享存储,缓存,数据库等,这样避免容器发生位置迁移后导致状态数据不可访问。 具体到存储技术的选择,应该根据应用的场景来
这个问题有很多复杂的影响因素,包括技术和非技术的。不同的组织情况不尽相同。 如果仅从技术角度、工作复杂程度来说,我们的经验是:- 考虑自身的技术能力,包括开发能力、运维能力。例如PCF等要求银行对应用代码开发的掌
流行的各种容器集群管理系统都支持服务编排,用yml格式的文件进行描述,但Swarm、K8S、Rancher Cattle等各自的服务编排语法并不统一。如果直接使用这些系统的编排语法,当未来重新选择容器管理系统的类型时,已经积累的应用
这个问题说以银行内部已有监控系统为前提,那么我认为问题的场景是需要容器平台和已有监控系统进行对接。在这个前提下,我个人的想法是: 首先监控是分层的,可以分为系统层面、应用层面、服务层面。 对于系统层面,主要是针
容器常被用来运行需要快速故障迁移、弹性伸缩的应用或微服务,因此容器中运行的应用,在运行的过程中随着迁移、弹性伸缩的发生,应用日志很可能会在不同的运行节点中产生,对应用通过日志进行监控、问题排查带来了很大的麻烦
考虑好定位和使用的场景,最好有应用部门人员参与推动;结合自身的技术能力和现有系统对接需求,做好技术验证。
成本包括:软件+定制开发、相关硬件资源(控制节点、网络资源、分配的存储资源等)、运维人力成本。
容器和微服务引入的性能、效率问题,稳定性问题等,必须要重视监控系统、日志系统的建设;另外微服务的合理划分也是重要问题。
一般来说,都会包含几个部分:资源池管理(包括计算节点的管理、网络方案、存储方案等)、应用管理(包括建模、服务编排、运行策略管理等)、监控方案、日志方案、多租户管理、高可用方案、连续性方案、安全方案等 这个和希望把
商用方案有:PCF、OpenShift,优点是成熟,集成度高、功能全;缺点是不够灵活、定制空间相对小纯开源方案:Kubernetes、Swarm、Mesos、Rancher等;优点是灵活;缺点是需要考虑众多走边对接的开源方案
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30