是时候祭出这张图了https://landscape.cncf.io/images/landscape.png
这部分具体请参考相关答疑资料。master可根据实际情况扩容(包括master服务和etcd)应用节点可以根据不同类型应用节点(有无状态、是否对底层有依赖:如gpu、是否对持久化有要求:如localpath)扩容infra节点需要规划,按需分割多
如果是单纯的docker,整体管理模式和vm类似。只是除传统宿主机监控运维外、再增加容器的监控运维。需要额外注意对于docker服务可用性的监控(因为部分版本docker服务存在bug)如果是k8s,包括宿主机、容器基础服务、应用层三
很大的问题。k8s官方有个汇总见https://kubernetes.io/docs/concepts/security/overview/从宏观角度,容器各层次具有不同best practices。比如网络networkpolicy,默认最好跨ns访问全堵塞,按需开放。比如容器避免root运
问题1,工作节点和infra节点必须分开(包括ingress、efk等)。workload节点配置根据应用同质化情况(比如是否对下层计算资源有要求、io要求、网络要求、cpu内存要求等等)适当区分。但需要避免节点资源过少导致容器不能有效调
参考官方链接https://kubernetes.io/docs/concepts/cluster-administration/networking/如果是商业方案,结合供应商本土化能力和网络可见性、虚拟网络性能损失等指标评估如果是开源方案,Flannel、Calico算是比较流行的,
回答这个问题需要思考docker有什么优势,解决了什么问题不解决什么问题。集装箱、api级别隔离和限制、轻量。这是为什么一般无状态应用和标准化的中间件会通过容器方案实现。同样,如果涉及重型应用或中间件数据库,我们需
监控这个范畴一般分为logging,metrics,tracing 容器平台内部的或容器相关中间件平台的可暴露metrics,通过Prometheus监控。后者也提供很多exporter或sdk方便集成。参考https://prometheus.io/docs/instrumenting/expo
可以根据几个维度看待:1.对于底层资源的绑定和依赖情况:如计算密集与否、gpu、大IO等等2.应用有状态无状态。是否涉及持久化,如san实现的local storage pv3.应用行为:针对不同应用特点进行隔离,注意东西流量
k8s本身不负责上面运行服务的灾备。需要逐层思考这个问题。架构上可以提一个思路,k8s下层的容器调度(scheduling framework)和存储调度(CSI和PVC storageclass)都是插件式的,可按需进行定制和扩展。但高可用本身,见过很多
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30