看业务受众。如果是面向企业,由于业务链路长,建议从顶层往下解构,到level3之后再考虑服务化(而不是微服务化),这个和成熟度有关如果业务面向C或业务链路短,可以考虑通过下层快速迭代演进。
弹性、轻量、快速部署、自动扩容和自愈
独立构建,涉及基础平台和上层服务。前者短期手工运维,但通过开发逐步自动化。后者通过开发实现。支撑人员和运营容器数量关系不大,但和上层开发服务的数量正相关。关键点:开发从上往下做。
不理解部署指物理架构还是什么高可用架构参考:https://kubernetes.io/docs/setup/independent/high-availability/容量规划参考:https://kubernetes.io/docs/setup/cluster-large/
需要考虑多个层次,主要包括:容器主机:主机本身的安全设置、SELinux的启用、Cgroups和Namespaces使用等容器镜像:基础镜像使用、基础镜像更新和漏洞扫描等容器仓库:通过建立TLS仓库,并通过HTTPS绑定,这样Docker只能从授信的仓
第一个:人。kubernetes学习曲线比起原生docker高很多,如何掌握学习脉络?第二个:组织。传统稳态组织和敏态组织的演化和融汇。第三个:文化。如何良性互动?
需要考虑下使用容器的初衷,究竟是业务的敏捷弹性需求触发呢还是交付复杂性需求初衷同时需要注意:资源利用率提升导致费用的节省、固定资产投资费用前后差异、人员学习成本及能力依赖差异、开源文化收益
早期做过个实验,同样性能的服务器虚拟化性能损失基本在20%左右,而容器化几乎没有性能损失。具体可以通过sysbench进行测试。当然两者隔离性也不是一个级别。
楼上基本都说到了,具体可参考https://github.com/kubernetes/kubernetes/issues/66747
1.确认应用是有状态还是无状态2.针对有状态的应用需要通过存储卷进行挂载,不然容器销毁后持久化的东西将不再存在。具体参考https://docs.docker.com/storage/#next-steps docker应用打包推荐使用docker file,具体参考
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30