服务部署与迁移的步骤

193次阅读

共计 1614 个字符，预计需要花费 5 分钟才能阅读完成。

应用容器化是部署与迁移的第一步，需要设计并规划好镜像的构建方案，由于 Docker 镜像分层的特性，通常建议使用分层方式进行 Docker 镜像构建。

操作系统层：制作公司常用的系统版本如 CentOS、Ubuntu，可以在官方镜像的基础上添加自己需要的软件包。

运行环境层：在已经构建的操作系统层的基础上，把业务常用的运行环境都打包好，如 JDK7、JDK8、JDK8+Tomcat8、Python2、Python3 等通用模板。

应用层：在已经构建好了通用运行环境的基础上，根据应用再进行调整，然后将代码放进去即可。

应用容器化后，就需要考虑如何在 Pod 中运行，因为 Pod 是 Kubernetes 管理的最小单元，Kubernetes 不直接管理容器，而是管理 Pod，Pod 里面包含容器。需要考虑是一个 Pod 中放置多个容器，还是一个 Pod 中放置一个容器，同时需要考虑 Pod 的资源限制，健康检查，数据持久化等。

单一 Pod 如果出现故障，就会影响业务连续性，所以需要多副本，就像我们给一个 Web 应用做集群是一样的。Kubernetes 提供了不同的 Controller，需要根据应用的实际情况选择使用 Deployment、DaemonSet、StatefulSet、Job、CronJob 等，只需要在 Pod 的 YAML 模板上封装上对应的配置即可。

Deployment：封装了 Pod 的副本管理、部署更新、回滚、扩容、缩容等。

DaemonSet：保证所有的 Node 上有且只有一个 Pod 在运行。

StatefulSet：有状态的应用，为 Pod 提供唯一的标识，它可以保证部署和 scale 的顺序。

Job：使用 Kubernetes 运行单一任务。

CronJob：使用 Kubernetes 运行定时任务。

使用 Deployment 通过多副本的方式保证了 Pod 的高可用和横向扩展，那么就需要考虑负载均衡，Kubernetes Service 就是实现此功能，为应用创建对应的 Service。目前 Service 的负载均衡支持两种实现方式：iptable 和 ipvs。

集群内部可以直接使用 Service Name 进行通信，因为在集群中定义的每个 Service，都会被指派一个 DNS 名称，外部要访问到 Kubernetes 集群，由于网络路由不通（也可以使用其它手段打通），可以通过 Node Port、LoadBlancer、外部 IP 等对外暴露访问。不过这些都可以理解为 4 层的负载均衡，如果要实现 7 层的负载均衡，Kubernetes 提供了 Ingress。

在 Kubernetes 中由 Ingress Controller 来实现 Ingress 的功能，这个控制器比较特殊，因为其它的控制器基本上都是 kube-controller-manager 这个服务的一部分，而 Ingress Controller 确是独立的。

容器中的存储都是临时的，因此 Pod 重启的时候，内部的数据会发生丢失。实际应用中，我们有些应用是无状态，有些应用则需要保持状态数据，确保 Pod 重启之后能够读取到之前的状态数据，有些应用则作为集群提供服务。这三种服务归纳为无状态服务、有状态服务以及有状态的集群服务，其中后面两个存在数据保存与共享的需求，因此就要采用容器外的存储方案。

在 DevOps 的部署流水线中，我们强调代码和配置的分离，这样更容易实现流水线的编排。在 Kubernetes 中提供了 ConfigMap 资源对象，其实 ConfigMap 和 Secret 都是一种卷类型，可以从文件、文件夹等途径创建 ConfigMap。然后再 Pod 中挂载使用。

正文完

星哥说事-微信公众号