基于K8S的容器云平台如何部署微服务？
|
通过提供api来分析和操作此流量，Service Mesh为跨组织的运行时操作提供了标准化的机制——包括确保可靠性、安全性和可见性的方法。与任何好的基础架构层一样，Service Mesh采用的是独立于服务的构建方式。 请参考：https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/ Q7: dubbo，zookeeper环境下，K8S的问题？ A7： 遇到过的问题 1.如果k8s上的应用仅仅是consumer，应该是没问题的，不管provider是在k8s集群内部还是外部 2.如果k8s上的应用是provider，注册到zk时是容器地址，这时如果consumer如果在集群内部容器方式运行是能访问到provider的，如果consumer在集群外部，那就访问不到，也就是你说的情况吧。 这个时候需要做一些路由策略: 设置consumer所在网段到k8s内部网段下一跳为k8s集群内部某一个节点即可，我们在腾讯云和阿里云上就是这么做的，VPC内非K8S节点也可以直通K8S集群内部overlay网络IP地址 通过api gateway来暴露需要对外的API。gateway不仅可以打通网络，还可以隐藏内部api，方便api治理 三、金融行业容器云微服务实践篇 Q1: 金融行业的微服务架构一般是怎样的，案例有哪些？ A1： -微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。 -微服务架构的优点： 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 微服务能使用不同的语言开发。 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。 微服务允许你利用融合最新技术。 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。 -微服务架构的缺点： 微服务架构可能带来过多的操作。 需要DevOps技巧。 可能双倍的努力。 分布式系统可能复杂难以管理。 因为分布部署跟踪问题难。 当服务数量增加，管理复杂性增加。 -微服务适合哪种情况： 当需要支持桌面，web，移动智能电视，可穿戴时都是可以的。 甚至将来可能不知道但需要支持的某种环境。 未来的规划，将以产业链延伸、客户导向及互联网+为战略发展方向，需要BI分析、业务动态扩展、以及敏捷的产品与服务对接和装配的能力支撑，基于以上的技术要求，优化建设支撑企业业务及应用运营的基础设施，结合基础资源现状，建立云计算技术能力，形成快速响应，可持续发展的下一代数据中心。 对比传统方案，容器云的方案，将在对微服务架构的支持、业务弹性扩容、自动化部署、产品快速上线、敏捷/迭代、全面系统监控等方面对IT部门带来全方位的提升。 目前金融行业案例： 银行：中国银联，工商银行，浦发银行、梅州客商银行等； 保险：太平洋保险，平安保险、中国人寿、大地保险、众安保险； 证券：海通证券 Q2: 部署在K8S上的微服务，如何实现有状态和无状态服务对于存储的要求？ A2： 容器的特性决定了容器本身是非持久化的，容器被删除，其上的数据也一并删除。而其上承载的应用分为有状态和无状态。容器更倾向于无状态化应用，可水平扩展的，但并不意味所有的应用都是无状态的，特别是银行的应用，一些服务的状态需要保存比如日志等相关信息，因此需要持久化存储。容器存储大致有三种存储方案： （1）原生云存储方案：按照纯粹的原生云的设计模式，持久化数据并不是存储在容器中，而是作为后端服务，例如对象存储和数据库即服务。这个方案可以确保容器和它们的数据持久化支持服务松耦合，同时也不需要那些会限制扩展的依赖。 （2）把容器作为虚拟机：利用容器带来的便携性的优点，一些用户将容器作为轻量虚拟机来使用。如果便携性是迁移到容器的原因之一，那么采用容器替代虚拟机来安装遗留应用是这种便携性的反模式。由于大卷中存储数据是紧耦合在容器上，便携性难以实现。 （3）容器持久化数据卷：在容器中运行的应用，应用真正需要保存的数据，可以写入持久化的Volume数据卷。在这个方案中，持久层产生价值，不是通过弹性，而是通过灵活可编程，例如通过设计的API来扩展存储。这个方案结合了持久层和或纯云原生设计模式。 Docker发布了容器卷插件规范，允许第三方厂商的数据卷在Docker引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准，就可接入Docker容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装，从而实现和Docker容器的对接。可以说，驱动程序实现了和容器引擎的北向接口，底层则调用后端存储的功能完成数据存取等任务。目前已经实现的Docker Volume Plugin中，后端存储包括常见的NFS，GlusterFS和块设备等。 K8S中的持久性存储主要还是通过PV、PVC和StorageClass来实现。 对于无状态服务，存储可能是不必要的，但是对于由状态服务，需要各种类型的存储来保持状态。在K8S中，PV提供存储资源，PVC使用存储资源，二者是供应者和消费者的关系，那么服务是如何把数据存储到PV上的呢？ 我们知道K8S中服务运行在POD中，因此在POD的YAML定义文件中，就需要定义PVC，并指定要关联的PVC名称，然后PVC会根据自身的YAML文件定义绑定合适的PV，流程就是：POD->PVC->PV,当然，这是静态供给方式，静态供给的特定就是先有PV再有PVC。 对于动态供给方式，就需要定义storageclass，并在存储类的YAML文件中声明存储卷供应者，如aws-ebs、ceph-rbd和cinder等，当POD需要存储的时候，再动态创建PV，其特点就是先PVC再PV； 当然，存储这块本身有很多需要考虑的地方，最佳答案还是官网 https://kubernetes.io/docs/concepts/storage/persistent-volumes/ 这里有两个扩阅读，关于容器原生存储： https://www.linuxfoundation.org/press-release/opensds-aruba-release-unifies-sds-control-for-kubernetes-and-openstack/ https://github.com/openebs/openebs Q3: kubernets如何Devops实现持续部署发布测试全流程？ A3： 使用原生kubernets实现CI/CD最大的弊端，就是你需要自己搞定Jenkins、Registry，以及外围的ELK监控、grafana等等东西，单是部署这些都要花费大量时间。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
