设为“星标”，好文章不错过！
相信很多Java从业者在熟悉了微服务开发后，自以为用SpringCloud已经成功打造了微服务架构帝国，Java已经垄断微服务领域，殊不知当引入k8s后，SpringCloud却和CloudNative的生态发展脱轨了。
从年的SpringBoot
年10月，MikeYoungstrom在Springjira中创建了一个功能需求，要求在Spring框架中支持无容器Web应用程序体系结构。他建议通过main方法引导的Spring容器内配置Web容器服务。这一需求促成了年初开始的SpringBoot项目。年4月，SpringBoot1.0.0发布。从那以后，一些SpringBoot小版本开始出现。
SpringBoot1.1（年6月）：改进的模板支持，gemfire支持，elasticsearch和apachesolr的自动配置Springboot1.2（年3月）：升级到servlet3.1/tomcat8/jetty9和spring4.1，支持banner/jms/SpringBootApplication注释Springboot1.3（年12月）：升级到spring4.2，新的spring-boot-devtools，缓存技术的自动配置（ehcache，hazelcast，redis，guava和infinispan）以及完全可执行的jar支持Springboot1.4（年1月）：升级到spring4.3，couchbase/neo4j支持，启动失败分析和RestTemplateBuilderSpringboot1.5（年2月）：支持kafka/ldap，第三方库升级，放弃对CRaSH支持和执行器日志终端用以动态修改应用程序日志级别Springboot的简便性使java开发人员能够快速大规模地应用于项目。Springboot可以说是Java中开发基于RESTful微服务Web应用的最快方法之一。它也非常适合docker容器部署和快速原型设计SpringBoot2.0.0，于年3月1日发布，新版本特点有：基于Java8，支持Java9；支持Quartz调度程序；支持嵌入式Netty，Tomcat,Undertow和Jetty均已支持HTTP/2；执行器架构重构，支持SpringMVC,WebFlux和Jersey；对响应式编程提供最大支持；引入对Kotlin1.2.x的支持，并提供了一个runApplication函数，用Kotlin通用的方式启动SpringBoot应用程序。一直到SpringCloud，第一批选型它的大公司很早就构建出了完整微服务生态，很多解决方案也被开源，很多坑点已被国内巨头踩完所以相当稳定。对于很多想要使用微服务架构的中小公司，这绝对是最佳进场时机，直接使用SpringCloud全家桶，绝对是稳定而正确的微服务架构选择。
但当你所在公司引入k8s后，就变天了。
k8s和SpringCloud的激烈冲突
Java生态的SpringCloud可谓是迄今最完整的微服务框架，基本满足所有微服务架构需求，网上教程也不胜枚举。但也因为SpringCloud生态过于完整，而如今k8s又大行其道，当我们把基于SpringCloud开发的服务放到k8s后，一些机制就不受k8s生态管控了。
因为从扩展部署、运维角度出发的k8s，在最原始容器、应用部署及网络层管理的基础上，已逐步实现并贴近应用层的需要，一些微服务架构下的基础需求（如：ServiceDiscovery、APIGateway等）开始直接或间接被纳入k8s生态。导致双方有很多组件功能重叠，只能择一而终。比如一旦你选了SpringCloud的解决方案，就得放弃k8s那边的机制。
SpringCloud官方提供的解决方案
为解决该问题，官方在Github上提供了开源方案，说明如何以SpringCloud整合Kubernetes生态下的元件，主要讨论从原本组件架构过度并一直到Kubernetes原生环境后的处理方法