随着本文逐步学习使用Kubernetes开源平台和Docker创建用于构建微服务的持续交付配置。
在我之前的一篇文章中，描述了一个用Docker和Jenkins构建微服务的持续交付配置的例子。 这是一个简单的配置，只使用Docker Pipeline Plugin来构建和运行带有微服务的容器。 这个解决方案有一个很大的缺点 - 我们不得不链接所有的容器，以提供部署在这些容器内的微服务之间的通信。 今天，我将向您展示一个聪明的解决方案，帮助我们避免这个问题 - Kubernetes。
原理
Kubernetes是一个最初是由Google设计的开源平台，用于在主机集群之间自动部署、扩展和运行应用程序容器，提供以容器为中心的基础架构。 它具有许多对于在生产中运行的应用程序特别有用的功能，如服务命名和发现、负载均衡、应用程序运行状况检查、横向弹性伸缩和滚动更新等。 在进入例子之前，我们应该知道Kubernetes的几个重要概念。
Pod - Kubernetes的基本单元。 它可以由一个或多个容器组成，这些容器在同一个物理主机内，并共享相同的资源。 在pod内部署的所有容器都可以通过localhost看到其他容器。 每个Pod在集群中具有唯一的IP地址。
Service - 一组一起工作的Pod。 默认情况下，Service在集群内部公开，但也可以暴露在集群外部的外部IP地址上。 我们可以使用以下四种方式之一来暴露它：ClusterIP、NodePort、LoadBalancer和ExternalName。
Replication Controller （RC） - 一种特定类型的Kubernetes控制器。 它通过在集群中运行指定数目的pod副本来处理复制和扩展。 如果底层节点发生故障，它也负责替换失败Pod。
Kubernetes集群的高可用配置不是一件容易的任务。 幸运的是，有一个工具可以让本地运行Kubernetes更简单 - Minikube。 Minikube可以在虚拟机内部运行单节点集群，这对于想要尝试的开发人员来说非常重要。 开始真的很简单，对于Windows上的例子，您必须下载minikube.exe和kubectl.exe，并将它们添加到PATH环境变量中。 然后，您可以使用minikube start命令从命令行启动它，并通过调用kubectl命令来使用几乎所有的Kubernetes功能。 命令行选项的另一种选择是Kubernetes Dashboard。 它可以通过调用minikube仪表板命令启动。 我们可以从UI仪表板创建，更新或删除部署，还可以列出并查看所有Pod、Service、Ingress、RC等的配置。如下图所示是Kubernetes Dashboard，其中包含例子的部署列表：
应用
我们的例子中的微服务体系结构的概念与我在本文开头提到的有关Docker和Jenkins的持续交付的文章中的概念非常相似。 例子也有Account和Customer的微服务， Customer Service在搜索Customer帐户的同时与Customer Service进行交互。 我们不使用网关（Zuul）和发现（Eureka）Spring Boot服务，因为我们在Kubernetes中内置这些机制。 这是一张图解说明所提出解决方案的架构。 每个微服务的pod由两个容器组成：第一个是微服务应用程序，第二个是Mongo数据库。 Account和Customer的微服务都有自己的数据库存储所有的数据。 每个Pod都是作为服务暴露的，并且可以通过在Kubernetes上的名字进行搜索。 我们还配置Kubernetes Ingress，它充当我们微服务的网关。
此例子的源代码在GitHub上提供。 它由两个模块组成：Account Service和Customer Service。 它基于Spring Boot框架，但不使用除Feign客户端之外的任何Spring云项目。 这里是Account Service的dockerfile。 我们使用一个小的openjdk image - alpine。 因此，使用标准的openjdk作为base image时，我们的结果image大约有120MB而不是〜650MB。
FROM openjdk:alpine
MAINTAINER Piotr Minkowski
ADD target/account-service.jar account-service.jar
ENTRYPOINT ["java", "-jar", "/account-service.jar"]
EXPOSE 2222
为了启用MongoDB支持，我将spring-boot-starter-data-mongodb依赖关系添加到了pom.xml中。 我们还必须提供连接数据到application.yml并用@Document注释实体类。 最后，声明存储库接口扩展MongoRepository，其中实现了基本的CRUD方法。 我们添加两个自定义查找方法：
public interface AccountRepository extends MongoRepository {
public Account findByNumber(String number);
public List findByCustomerId(String customerId);
}
在Customer Service中，我们打算从Account Service调用API方法。 这是声明式REST客户端@FeignClient声明。 所有具有Account Service的Pod在服务名称和默认服务端口2222下均可用。此类设置是Kubernetes上服务配置的结果。 我将在下一节中对其进行描述。
@FeignClient(name = "account-service", url = "http://account-service:2222")
public interface AccountClient {
@RequestMapping(method = RequestMethod.GET, value = "/accounts/customer/{customerId}")
List getAccounts(@PathVariable("customerId") String customerId);
}
我们的微服务的docker image可以使用下面的命令来构建。 构建之后，您应该将该image推送到docker hub 或您的registry。 在下一节中，我将介绍如何在Kubernetes上使用它们。 所描述的微服务的Docker镜像也可以在我的Docker Hub公共存储库上用作piomin / account-service和piomin / customer-service。
docker build -t piomin/account-service .
docker push piomin/account-service
部署
您可以使用kubectl运行命令、Minikube dashboard或使用kubectl create命令的YAML配置文件在Kubernetes上创建部署。 我将向您展示如何从YAML配置文件创建所有资源，因为我们需要一步创建多容器部署。 这是Account Service的部署配置文件。 我们必须提供部署名称，image名称和暴露端口。 在副本属性中，我们正在设置创建的pod的请求数量。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: account-service
labels:
run: account-service
spec:
replicas: 1
template:
metadata:
labels:
run: account-service
spec:
containers:
- name: account-service
image: piomin/account-service
ports:
- containerPort: 2222
protocol: TCP
- name: mongo
image: library/mongo
ports:
- containerPort: 27017
protocol: TCP
我们正在通过运行下面的命令来创建新的部署。 相同的命令用于创建Service和ingress。 只有YAML文件格式不同：
kubectl create -f deployment-account.yaml
现在，我们来看看Service配置文件。 我们已经创建了部署。 如您所见，dashboard image已从Docker Hub中取出; pod和副本集已经创建。 现在，我们想在外面暴露我们的微服务。 这就是为什么需要Service。 我们还在其默认端口上公开Mongo数据库，以便能够连接数据库并从MongoDB客户端创建集合。
kind: Service
apiVersion: v1
metadata:
name: account-service
spec:
selector:
run: account-service
ports:
- name: port1
protocol: TCP
port: 2222
targetPort: 2222
- name: port2
protocol: TCP
port: 27017
targetPort: 27017
type: NodePort
在为Customer Service创建类似的配置后，我们已经暴露了我们的微服务。在Kubernetes内部，它们在默认端口（2222和3333）和服务名称上可见。这就是为什么在客户服务REST客户端（@FeignClient）中，我们声明了URL http：// account-service：2222。无论创建了多少个Pod，服务将始终在该URL上可用，并且请求在所有Pod之间进行负载均衡。如果我们希望访问Kubernetes以外的每个服务，例如，在Web浏览器中，我们需要使用在容器默认端口下方可见的端口来调用它 - 在该Account Service的示例中，它是31638端口，并且对于Customer Service， 31171端口。如果您在Windows上运行Minikube，则您的Kubernetes可能位于192.168.99.100地址下，因此您可以尝试使用URL http://192.168.99.100:31638/accounts呼叫帐户服务。在进行这样的测试之前，您需要在Mongo数据库和用户微型/微型（在application.yml中为该服务设置）上创建一个集合。
好了，我们在两个不同的端口下有两个微服务，这不完全是我们所需要的。 我们需要一些IP可用的网关，通过匹配请求路径来代理我们的请求，以及确切的服务。 幸运的是，Kubernetes也提供这样的选项。 这个解决方案是Ingress。 这里是YAML入口配置文件。 定义了两个规则，第一个是Account Service，第二个是Customer Service。 我们的网关在micro.allhost名称和默认HTTP端口下可用。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: gateway-ingress
spec:
backend:
serviceName: default-http-backend
servicePort: 80
rules:
- host: micro.all
http:
paths:
- path: /account
backend:
serviceName: account-service
servicePort: 2222
- path: /customer
backend:
serviceName: customer-service
servicePort: 3333
为了使网关能够正常工作，最后一件事就是将下列条目添加到系统主机文件（Linux的/ etc / hosts和windows的C： Windows System32 drivers etc hosts）中。 现在，您可以尝试从您的网络浏览器调用http：//micro.all/accounts或http：//micro.all/customers/ {id}，该帐户在后台也调用帐户服务。
[MINIKUBE_IP] micro.all
总之，Kubernetes是微服务集群管理和编排的好工具。 它在快速发展中，仍然是一个比较新的解决方案。 它可以与Spring Boot堆栈一起使用，或者作为Spring Cloud Netflix OSS（这似乎是目前最流行的微服务解决方案）的替代品。 它还有一个UIdashboard ，您可以在其中管理和监视所有资源。 生产级配置可能比使用Minikube的单一主机开发配置更复杂，但我不认为这是针对Kubernetes。
译者介绍：
楼炜 Jet，云技术社区金牌翻译，现任云星数据副总裁兼研发中心总监，业内资深的云计算专家， 10年云计算经验，7年+ IaaS、PaaS经验。著有： 《企业级IaaS架构的深度解析》、《企业级私有云构建的架构师阵型及架构策略》等文章
相关阅读：
高端私有云项目交流群，欢迎加入！
2017年云市场十大热词，展望2018年
RightScale：2017年云计算调查报告|附下载
Forrester：混合云评测报告
Gartner：2018年基础设施和运营的十大技术趋势
震撼：AWS放弃XEN 改用KVM作为新的虚拟化引擎
Red Hat开始将它的OpenStack平台移动到容器
向云上迁移数据时如何避免停机和中断
如何从传统IT技能转型进入云计算
云管理平台实践指南
