随着k8s技术的日臻发展成熟，传统基于物理/虚拟机架构部署体系向容器平台迁移的步伐愈加快速。本文谨以SpringCloud微服务架构体系迁移到k8s平台为讲述范围，以个人实践为案例，分享如何从传统的微服务架构体系迁移到k8s平台，也期待后续与各位读者进行跟广泛、深入的交流。

词条

Kubernetes：本文以k8s作为简称

SringCloud：作为Java平台中最流行的开箱即用微服务架构体系

容器：可以理解为物理机/虚拟机，运行应用程序的最小单元，比熟知的vm要轻量级。简单举例，在常见的vmware或者vm visualbox中创建一个可运行的系统（例如window或linux）大概的时间单位是小时级或者分钟级，在容器平台可以秒级启动一个可运行的系统。

目的

本文仅以SpringCloud微服务架构体系迁移到k8s平台为讲述范围，尝试从个人接触的内容来描述如何从传统的微服务架构体系迁移到k8s平台。其中概念级的内容过多，某些功能性的概念请大家自行search。另外本文只是提供抛砖引玉的作用，k8s浩如烟海，每个细节都可以拿出来单独成专题，本文目的旨在“走进k8s”。

面向对象

本文面向熟悉SpringCloud以及稍懂容器知识的开发者，某些概念上不再做具体的说明。

一、k8s的形态

k8s运行态的组成

宿主机

K8s是管理多个容器化应用的平台，底层需要运行于一个物理集群上，这个物理集群即称之为宿主机。

命名空间

K8s支持管理多个虚拟集群，这些虚拟集群被称之为命名空间。一个服务可以运行于多个命名空间之中，他们是隔离的。

命名空间适用于多个团队或多个项目的场景，数量少的时候无需考虑多个命名空间。在同一个命名空间内，资源名称是唯一的。

POD

在命名空间中运行的最小单元，可将之视作一个个的虚拟机，我们的应用程序都是运行于POD中。POD中只提供了运行程序的最小依赖环境，由于它足够小，启动速度达到了秒级。Pod支持多种容器环境，Docker作为最流行的容器环境，只是POD支持的一种。

Chart/Yaml定义

Chart/Yaml中定义了如何从一个容器镜像部署到k8s上并对外提供服务的过程，同时定义了对部署的要求、依赖环境的要求、运行副本数的要求和权限的要求等。正常情况下，运行一个容器需要至少定义deployment、service，此部分可在不同的文件中定义，也可以在一个文件中集中定义。本文以运行一个镜像所需的最小配置做说明，运行yaml文件后，即可将我们的镜像在k8s中运行起来了。

其他说明

通过以上定义，我们只是实现了将镜像运行到k8s上，但是还有许多内容未说明，例如对依赖环境的要求、卷、弹性伸缩策略等，后续我们将在更多的文档中进行专题说明。

二、完全使用云原生的SpringCloud

SpringCloud在非k8s生态与k8s的生态对比

在非k8s体系中，需要借助外部的注册中心完成服务的注册及发现，然后再使用基于服务名称的调用模式，统一入口的网关也需借助SpringCloudGateway/Zuul等独立插件；在k8s中，可直接使用云原生的k8s注册中心完成服务的注册及发现，网关可使用ingress完成类似的工作，然后类似于非k8s的以服务名称调用模式完成微服务的调用。

通过不同的形态可发现，在k8s中已提供了完整的运行SpringCloud的原生生态，并且通过SpringCloudKubernetes的顶层实现，完全屏蔽了底层，我们可以在微服务的层面完全无感的切换至k8s平台，甚至在应用程序层完全无侵入。

三、SpringCloud程序在k8s中的使用形态

基于服务发现的方式调用微服务（一个命名空间）

在SpringCloud体系下，常用微服务的调用方式为OpenFeign以及Ribbon（RestTemplate）。在引入使用SpringCloudKubernetes后，即可按照原有方式进行调用使用，此处需注意：

●　取消其他引入的注册中心服务，例如consul、zookeeper等

●　引入kubernetes-discovery的依赖

●　取消引入spring-cloud-loadbalancer

●　引入kubernetes-loadbalancer

引入后，在非k8s环境下直接运行会报错，因为没有k8s环境，对应的内容找不到，autoconfig无法加载k8s环境，需打包在k8s环境下运行。

备注：

●　此种方式在非大型应用服务场景足够使用，也无需考虑多命名空间的问题，直接使用一个命名空间即可

●　一样的@EnableDiscoveryClient，一样的openfeign，一样的Ribbon，无需任何更改

●　配置文件中设置spring.cloud.loadbalancer.ribbon. enabled=false

跨命名空间的互通访问

由于k8s的特殊性，命名空间本就是为了隔离使用，因此当从跨命名空间访问时，需要注意如下要求：

●　开通权限，保证可发现多个命名空间的服务。权限可参考rbac，主要分配list、get和watch

●　服务名称的唯一性。确保同样的服务名提供的是同样的服务

●　扫描所有命名空间，配置文件中设置spring.cloud.kubernetes.discovery. all-namespaces=true

●　针对权限的开通，需要严格按照国家监管或客户方的要求，如果要求严格遵守隔离准则，则只能访问本命名空间

基于Submariner的跨集群互通访问

Submariner是rancher开源为跨k8s集群间的pod通讯提供网络连接的组件，目的是解决k8s集群间的连接障碍问题。部署Submariner之后，其连接方式的格式为：集群名.服务名.命名空间.集群域名（svc.clusterset.local）：端口号/api的形式。注意，在本集群访问时，可不加集群名。此种方式需注意：

●　访问服务必须添加端口号

●　集群域名一般是固定名称

●　使用openfeign或者ribbon时不能只按照服务名称进行调用

基于Consul的跨集群互通访问

如果我们仍然希望基于传统的以服务发现的方式进行微服务调用时，在多个k8s集群中进行互通访问，则可以在集群中间架设Consul，利用Consul DNS与k8s进行打通，实现从微服务调用上的统一规范。利用中间Consul层，即可以实现k8s之间互通。值得注意的是，此种方式也可以实现k8s与非k8s微服务集群的互通。其形态如下：

经由此种方式后，k8s集群的微服务与非k8s集群的微服务，通过Consul进行统一管理，并在k8s的注册中心中也实现了数据同步。这为异构集群的互通提供了服务发现的保障。使用此种方式后，需注意：

●在k8s集群内发起跨集群调用时均需添加service.consul后缀，以标识此服务是外部服务

●注册到Consul的k8s服务，其名称会自动添加命名空间：服务名-命名空间。也可自定义添加前缀集群名，即：集群名-服务名-命名空间

●注册到Consul的服务，请不要注册ClusterIP类型的服务，此种方式非是对外访问模式，会将pod的虚拟ip进行注册，造成最终无法访问

●调用集群外部微服务格式为：服务名. service.consul:端口号/api

●非k8s集群部署的微服务，调用k8s服务时直接使用名称即可发起调用

●需要在每个Consul集群中安装Consul DNS，并且配置Consul地址（静态IP）

●如果使用kube-dns则需配置stubDomains，指向Consul的地址（静态IP）

●如果使用CoreDNS则需配置forward指向Consul的地址（静态IP）

●详情可参见Consul官方文档https://www.consul.io/docs/k8s/dns