如果是共享计算节点的集群,建议按照计算类型和内存使用类型做区分。绝大部分应用都可以共享集群节点,但是一些计算或者网络I/O非常密集型的应用(如ES,Spark),建议还是用单独集群承载。此外,对于网络模型有特殊要求,需要使用宿
部分能力可以复用,比如主机入侵检测可以通过增加容器测的检测,兼顾到容器入侵检测。容器和传统架构下,安全的最大区别是容器相关的漏扫、渗透测试、镜像扫描可以左移到测试的版本环境做,因为版本环境的镜像就是用于生产上
目前很多主流安全厂商,已经在主机入侵检测里加入了对于容器进行入侵检测的能力,比如提权、高位命令、逃逸、恶意程序等,只需要在容器宿主机山部署相关的Agent。不建议通过sidecar做这种事情,资源和管理开销太大。另外,容器
容器安全加固方面,也有相关的最佳实践,很多安全公司现在都有这方面的实践和建议,比如对dockerfile的安全配置建议,对于k8s yaml的安全配置建议。这些建议很多是来自CIS,可以根据自己的实际情况选择使用。CIS对于k8s组件的
数据持久化主要有两种方式实现,一种是通过PVC提供文件系统存储或者块存储,一种是通过远端的分布式对象存储提供对象存储。对于非数据库类的应用,PVC的后端可以使用分布式块存储(NVMe SSD作为缓存,Sata作为存储盘),通过专用
容器监控数据采集可以使用目前最主流的prometheus,数据的处理以及和应用的关联需要由额外的监控处理平台来做。这个平台可以是现有的监控平台,但是需要针对容器的特点做改造,主要的思路是面相应用和K8S对象(如node、控制
从我们行实践的结果看,是有必要的。没有容器技术,微服务落地是非常困难的,仅仅是资源管理就会及其复杂,更别提调度和编排了。当然,建设容器技术也是一个庞大的工程,不仅需要K8S+Docker,还需要匹配的自动化发布系统、监控系统
在采用underlay网络模型下,有两种思路供参考。一种是为每个应用namespace绑定一个地址段,按照地址段开通访问关系,一种是容器创建后,要将ip通知给网络自动化工具,由网络自动化工具将新ip加入提前配置好的策略组。
目前应该还没有微服务跨数据中心的合适技术,跨数据中心,需要解决微服务调度、服务发布的问题,还需要面对时延挑战。所以比较好的方法是一个应用的微服务尽量都尽量在一个数据中心部署,考虑容灾可以在另一个数据中心也部署
微服务并不是一定要使用队列和缓存,还是要看应用的性质和类型,一些对于消息丢失或者死信很敏感的应用,比如银行的核心交易系统,就需要对通常队列的使用方式做一定改造,死信也需要处理,因为这可能对应着一笔真正的交易。 从
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30