日志是应用服务运行过程中的一个关键环节,借助日志,我们可以排查定位问题,也可以借助集中化的日志管理平台(如ELK)来做一些必要的数据统计分析与监控告警。在 K8s 环境中,容器的日志有可能是通过 STDOUT/STDERR 输出(对于标准输出,前面 Docker笔记(十三):容器日志采集实践 有相关介绍可参考),并且一般也推荐将日志写到标准输出,但是也有一些特殊的场景,应用直接将日志写在容器内部的日志文件。对于容器的标准输出日志来说,Docker Engine 本身就提供了一个很好的日志采集能力,但是对于容器内部的文件日志采集,现在却并没有一个很好的工具能够去动态发现采集。因为在分布式的容器集群中,容器随着 Pod 调度被动态创建或删除,我们无法像虚拟机环境那样事先配置好日志采集路径等信息,目前的采集工具都是需要我们事先手动配置好日志采集方式和路径等信息,它无法自动感知到容器的生命周期变化或者动态漂移(一个 Pod 挂了,可能是在另一个节点上启动一个新的 Pod),无法进行动态的配置。因此,在 K8s 中进行日志采集将变得更为复杂。

Pod(容器组)是 Kubernetes 中最小的调度单元,可以通过 yaml 定义文件直接创建一个 Pod。但 Pod 本身并不具备自我恢复(self-healing)功能。如果一个 Pod 所在的节点出现故障,或者调度程序自身出现问题,以及节点资源不够或节点进入维护而驱逐 Pod 时,Pod 将被删除,且不能自我恢复。

因此,Kubernetes 中我们一般不直接创建 Pod, 而是通过 Controller(控制器)来管理 Pod。

前面我们对K8s的基本组件与概念有了个大致的印象,并且基于K8s实现了一个初步的CI/CD流程,但对里面涉及的各个对象(如Namespace, Pod, Deployment, Service, Ingress, PVC等)及各对象的管理可能还缺乏深入的理解与实践,接下来的文章就让我们一起深入K8s的各组件内部来一探究竟吧。下图是基于个人的理解梳理的一个K8s结构图,示例了各个组件(只包含了主要组件)如何协同。

通过前面两篇文章,我们已经有了一个“嗷嗷待哺”的K8s集群环境,也对相关的概念与组件有了一个基本了解(前期对概念有个印象即可,因为只有实践了才能对其有深入理解,所谓“纸上得来终觉浅,绝知此事要躬行”),本文从实践角度介绍如何结合我们常用的Gitlab与Jenkins,通过K8s来实现项目的自动化部署,示例将包括基于SpringBoot的服务端项目与基于Vue.js的Web项目。

Kubernetes是Goole开源的一个容器编排引擎,它支持自动化部署、大规模可伸缩、应用容器化管理 —— 百度百科。

接触K8s也有半年多了,也基于阿里云平台搭建了包含多级服务、目前运行较为稳定的K8s集群(感兴趣的可参考 k8s云集群混搭模式,可能帮你节省50%以上的服务成本k8s云集群混搭模式落地分享),但一直没来得及对其进行系统的学习,本系列文章还像以前Docker系列一样,以笔记的形式进行记录与分享,会包括理论与实践,感兴趣的同学可以关注,一起探索下目前较为流行的容器化及服务编排解决方案。