使用Kubernetes

我们已经在Docker容器上启动了示例微服务，甚至使用了CI和CD自动化管道，以便在本地计算机上运行它们。但是，开发人员可能会提出一个重要问题:我们如何在更大规模和生产模式下组织我们的环境，使我们能够在多台机器上运行多个容器?实际上，这正是我们根据云原生开发的思想实现微服务时必须要做的。事实证明，在这种情况下仍然存在许多挑战。假设开发人员在多个实例中启动了许多微服务，那么将会有大量容器需要管理。此时的很多操作(例如，在正确的时间启动正确的容器、处理存储的注意事项、向上或向下扩展以及手动处理故障等)对于开发人员来说都将是一场噩梦。 幸运的是，有一些平台可以帮助大规模地集群和编排Docker容器。目前，走在该领域前列的是Kubernetes。

Kubernetes是一个用于管理容器化工作负载和服务的开源平台。它可以充当容器平台、微服务平台、云平台等。它可以自动执行以下操作:跨不同计算机运行容器、向上和向下扩展、在容器之间分配负载，以及在应用程序的多个实例之间保持存储的一致性。它还具有许多其他功能，包括服务发现、负载均衡、配置管理、服务命名和滚动更新等。

当然，并非所有这些功能都对开发人员有用，因为Spring Cloud也提供了许多类似的功能。值得一提的是,Kubernetes不是唯一的容器管理工具。类似的工具还有DockerSwarm,它是Docker中提供的原生工具。但是，由于Docker已经宣布了对Kubernetes 的原生支持，所以它看起来也是一个很自然的选择。在详细讨论任何实际示例之前，开发人员应该知道关于Kubernetes的几个重要概念和组件。

概念和组件

使用Kubemetes时可能需要理解的第一个术语是pod,它是Kubermnetes 的基本构建块。pod表示集群中正在运行的进程。它可以由一个或多个容器组成，这些容器保证共存在主机上并将共享相同的资源。每个pod一个容器就是最常见的Kubernetes 用例。每个pod在集群中都有唯一的IP地址，但部署在同一pod中的所有容器都可以通过localhost与其他容器进行通信。

另一个常见的组件是服务。服务可以在逻辑上对一组pod进行分组，并定义访问它的策略。它有时被称为微服务。默认情况下，服务在集群内部公开，但也可以公开到外部IP地址。开发人员可以使用以下4种可用行为之一公开服务: ClusterIP、 NodePort.LoadBalancer和ExteralName。默认选项是ClusterlP。这会在集群内部IP.上公开服务，这也使得它只能从集群内部访问。

NodePort将公开每个节点的IP在静态端口上的服务,并自动创建ClusterIP以在集群内公开服务。反过来，LoadBalancer将使用云提供商的负载均衡器在外部公开服务，ExtermalName可以将服务映射到extemnalName字段的内容。这里还应该花点时间来讨论Kubernetes的副本控制:器( Replication Controller)。它通过在集群中运行指定数量的pod副本来处理副本和扩展。如果底层节点出现故障，它还负责替换pod. Kubermetes 中的每个控制器都是通过kube-contoller-manager 运行的独立进程。开发人员还可以在Kubernetes中找到节点控制器(Node Controller)、端点控制器( Endpoint Controller)以及服务账户和令牌控制器。

Kubernetes使用etcd键/值存储作为所有集群数据的后备存储。在集群的每个节点内都有一个名为kubelet的代理，它负责确保容器在pod中运行。用户发送给Kubernetes的每个命令都由kubeapi-server 公开的Kubernetes API处理。

当然，以上只是对Kubernetes 架构的一个非常简化的解释。有许多组件和工具必须正确配置才能成功运行高可用性Kubernetes 集群。这不是一项简单的任务， 它需要大量有关此平台的知识。幸运的是，有一个工具可以轻松地以本地方式运行Kubernetes 集群，这个工具就是Minikube.

通过 Minikube以本地方式运行Kubernetes

Minikube是一种工具， 可以按本地方式轻松运行Kubernetes。 它在本地计算机上的虚拟机内运行单节点Kubermetes集群。它绝对是开发模式中最合适的选择。当然，Minikube并不支持Kubernetes 提供的所有功能，只提供了对最重要功能的支持，包括DNS、NodePorts、Config Map、Dashboard 和Ingress等。

要在Windows上运行Minikube,需要安装虚拟化工具。当然，如果开发人员已经运行了Docker,那么很可能已经安装了Oracle VM VirtualBox。在这种情况下，除了下载并安装Minikube 的最新版本之外，不必执行任何其他操作。开发人员可以查看htps:/ithb.co/kubernetes/minikub/releasese和kubectl.exe， 其文本说明的地址为htps://storage.googleapis.com/kubernetes-release/release/stable.txt。文件minikube.exe 和kubect.exe都应包含在PATH环境变量中。此外，Minikube 还提供了自己的安装程序minikube itallrexe,它会自动将minikube.exe 添加到路径中。然后，开发人员可以通过运行以下命令从命令行启动Minikube。

$ minikube start

以上命令将初始化一个名为minikube 的kubectl上下文。它包含允许开发人员与Minikube集群通信的配置。现在可以使用kubectl 命令来维护由Minikube 创建的本地集群，并在那里部署容器。命令行界面的替代解决方案是Kubernetes 仪表板。可以通过调用minikube仪表板为节点启用Kubemnetes仪表板。开发人员可以使用此仪表板创建、更新或删除部署，以及列出和查看所有pod、服务、入口和副本控制器的配置。通过调用以下命令可以轻松地停止和删除本地集群。

$ minikube stop

$ minikube delete

部署应用程序

Kubernetes集群上现有的每个配置都由Kubernetes 对象表示。这些对象可以通过Kubernetes API进行管理，并且应该以YAML格式表示。开发人员可以直接使用该API, 但也可以利用kubectl命令行界面进行所有必要的调用。Kubernetes中新创建的对象的描述必须提供描述其所需状态的规范，以及有关该对象的一些基本信息。以下是应始终设置的YAML配置文件中的一些必填字段。

口 apiVersion: 这表示用于创建对象的Kubernetes API的版本。API 总是在请求中需要JSON格式，但kubectl会自动将YAML输入转换为JSON.

口 kind: 设置要创建的对象的类型。有一些预定义类型可用，如Deployment、Service、Ingress 或ConfigMap.

口 metadata: 这允许开发人员通过名称、UID或可选命名空间来标识对象。

口 spec: 这是对象的正确定义。规范的精确格式取决于对象的类型，并包含特定于该对象的嵌套字段。

一般来说，在Kubernetes.上创建新对象时，其kind是Deployment。在如下所示的Deployment YAML文件中，有两个重要的字段设置。第一一个字段是replicas,它指定了所需pod的数量。实际上，这意味着开发人员运行容器化应用程序的两个实例。第二个字段是spec.template spec contanrsimage,它设置将在pod中启动的Docker镜像的名称和版本。该容器将在端口8090上公开，而order-service服务也将在端口8090上侦听HTTP连接。

apiVersion: apps/v1

kind: Deployment

metadata:

name: order- service

spec:

replicas: 2

selector :

matchLabels:

app: order-service

template:

metadata:

labels:

app: order-service

spec:

containers:

name: order-service

image: piomin/order-service:1.0

env:

name: EUREKA_ DEFAULT ZONE

value:

ports:

containerPort: 8090

protocol: TCP

假设上述代码存储在文件order- deployment.yaml中，那么开发人员就可以使用命令管理方式在Kubernetes.上部署自己的容器化应用程序，如下所示。

$ kubectl create -f order - deployment. yaml

或者，也可以基于声明式管理方式执行相同的操作，如下所示。

$ kubectl apply一f order-deployment. yaml

现在开发人员必须为所有微服务和discovery-service 服务创建相同的部署文件。discovery-service服务的客体是一个非常希望了解的事项。开发人员可以选择使用基于pod和服务的内置Kubermnetes发现，但这里的主要目标是在该平台上部署和运行Spring Cloud组件，因此，在部署任何微服务之前，首先应该在Kubernetes上部署、运行和公开Eureka.以下是discovery-service 的部署文件，它也可以通过调用kubctl apply 命令应用于Kubernetes。

apiVersion: apps/v1

kind: Deployment

metadata:

name: discovery-service

labels:

run: discovery-service

spec:

replicas: 1

selector :

matchLabels :

app: discovery-service

template:

metadata:

labels:

app: discovery-service

spec:

containers :

-name: discovery-service

image: piomin/discovery-service:1.0

ports:

-containerPort: 8761

protocol: TCP

如果创建的是Deployment类型的对象，则Kubernetes会自动创建pod.它们的数量等于replicas 字段中设置的值。pod无法公开由部署在容器上的应用程序提供的API,它只表示集群上正在运行的进程。要访问在pod中运行的微服务提供的API, 必须定义一个服务。那么这里的服务是什么?

服务是一种抽象，它定义了一组逻辑pod和一个访问它们的策略。服务所针对的一组 pod通常由标签选择器确定。Kubernetes 提供了4种服务类型，最简单和默认的是ClusterP, 它在内部公开服务。如果要从集群外部访问服务，则应定义NodePort类型。此选项已在以下示例YAML文件中列出。现在，所有微服务都可以使用其Kubernetes服务名称与Eureka进行通信。

apiVersion: v1

kind: Service

metadata:

name: discovery-service

labels:

app: discovery-service

spec:

type: NodePort

ports:

一protocol: TCP

port: 8761

targetPort: 8761

selector :

app: discovery-service

事实上，部署在Minikube上的所有微服务都应该在集群外部使用，因为开发入员希望访问它们公开的API。为此，需要提供与前面示例中类似的YAML配置，当然也别忘记更改服务的名称、标签和端口。

在我们的架构中，现在应该只剩下最后一个组件还未介绍: API 网关。开发人员当然可以使用Zuul代理部署容器，但是这里我们想要介绍另一个流行的Kubernetes对象:Ingresso该组件负责管理通过HTTP公开的服务的外部访问。Ingress可以提供负载均衡、SSL终端和基于名称的虚拟主机。Ingress 配置YAML文件如下所示。请注意，可以在不同URL路径上的同--端口80上访问所有服务。

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: gateway- ingress

spec:

backend:

serviceName: default-http-backend

servicePort: 80

rules:

- host: microservices. example.pl

http:

paths:

path: / account

backend:

serviceName: account-service

servicePort: 8091

path: /customer

backend:

serviceName: customer -service

servicePort: 8092

path: /order

backend:

serviceName: order-service

servicePort: 8090

一path: /product

backend:

serviceName: product- service

servicePort: 8093

维护集群

维护Kubernetes 集群相当复杂。本节将演示如何使用一些基本命令和用户界面仪表板来查看集群.上当前存在的对象。这里不妨列出为运行基于微服务的示例系统而创建的元素。要完成此操作，首先可以通过运行kubectl get deployments命令显示部署列表，这将导致如图14.12所示的结果。

一个部署可以创建许多pod。开发人员可以通过调用kubectlgetpods命令来检查pod列表，如图14.13所示。

可以使用命令kubectl get services 显示可用服务的完整列表，如图14.15所示。这里有一些有趣的字段，包括一个表示集群内可用服务的IP地址(CLUSTER-IP)和一对端口(PORT(S)，它们的服务将在内部和外部公开。还可以在地址htp:///2. 168.99.100:31099上调用由account-service服务公开的HTTP API， 或者在地址ht://192.168.99.10031931上访问Eureka 用户界面仪表板。

小结

本章讨论了许多与Spring Cloud 无明显关联的主题，但本章中介绍的工具将允许开发人员充分利用迁移到基于微服务的架构的优势。当使用Docker、Kubernetes 或持续集成/持续交付(CICD)工具时，使用Spring Cloud进行云原生开发具有明显的优势。当然，所有提供的示例都已在本地计算机上启动，但开发人员可以参考这些示例来设想如何在跨远程计算机集群的生产环境中设计该过程。

本章向开发人员演示了如何简单快捷地从在本地计算机上手动运行Spring 微服务转移到从源代码构建应用程序的全自动化流程，使用应用程序创建和运行Docker镜像，并将其部署在由多台计算机组成的集群上。想要在同一章中描述Docker. Kubernetes 和Jenkins等复杂工具提供的所有功能并不容易，所以，本章的主要目的是让开发人员了解如何基于容器化、自动部署、扩展和私有云等概念设计和维护现代架构的宏观知识。

我们这个章节现在已经接近结尾了。我们已经讨论了与Spring Cloud 框架相关的大多数计划主题。下篇文章将展示如何使用Web上可用的两个最流行的云平台，从而允许开发人员持续交付Spring Cloud应用程序。

本文给大家讲解的内容是如何使用Kubernetes在实践中部署微服务

1.下篇文章给大家讲解的是云平台上的Spring微服务；

2.觉得文章不错的朋友可以转发此文关注小编，有需要的可以私信小编获取资料；

3.感谢大家的支持！