前言
《基于Kubernetes舵手集群的设计与实现》是我的毕业设计项目。本系统采用Kubernetes容器编排、基于JenkinsGitlab的CICD技术、EFK日志收集、Prometheus监控告警、Ceph后端存储和Harbor镜像管理，设计并实现了具有“源码一键部署”、“日志实时收集”、“监控告警展示”、“数据存储分析”和“镜像管理维护”五大模块的舵手集群系统。
拓扑图
总体架构图
日志收集架构图
原理
部署方案
(1) Kubernetes集群采用三主三从模式，从架构规划上防止单点故障，保证集群高可用性；
(2) 由bs-k8s-ceph-209、bs-k8s-gitlab-208、bs-k8s-harbor-207三节点组成后端分布式存储Ceph集群；
(3) Gitlab源码管理仓库是供开发工程师使用，独立于Kubernetes集群之外，既减轻了Kubernetes集群的负担又权限分明便于维护管理。
部署原理
(1) 开发工程师将项目源码合并到Master分支并推送到Gitlab源码管理仓库服务器；
(2) Gitlab Webhook感知到Master分支发生改动后触发Jenkins持续集成Pod在Kubernetes集群中临时启一个Jenkins-slave Pod，进行项目源码拉取、编译、测试、构建Docker镜像、并推送镜像到私有仓库Harbor；
(3) Jenkins通过Kubernetes deployment插件在Kubernetes集群中拉取推送到Harbor镜像仓库中的应用镜像制做成应用Pod，此时已经完成一键部署源码到Kubernetes集群；
(4) Traefik代理容器编排集群中的应用服务，将应用服务暴漏到公网供用户访问；
(5) EFK日志收集集群的Kibana界面可以展示采集到的已经发布的应用服务的日志信息，供运维工程师和开发工程师分析；
(6) Prometheus监控告警集群的Grafana展示界面可以实时刷新整个容器编集群和应用服务的运行状态，并将越限行为进行邮件告警发送给运维工程师；
(7) 舵手集群内所有有状态类应用程序的数据都存储在分布式存储集群Ceph中。
后续
《基于Kubernetes的舵手集群系统》是由我借鉴互联网现有拓扑架构图而独立设计并完成的项目，代表了我大学期间的最高水平，设计到了运维、开发、容器三个方面。但此项目并不完善如：缺乏微服务、Go项目不优秀等，还需要进行改动升级。此项目的监控部分、日志收集部分、数据存储部分依然存在不深入的问题，我会持续的进行优化下去。
大学不是终点，人生正式起步。道阻且长，我对自己有要求：今年的目标是完成容器生态圈之旅-第三章《容器编排工具Kubernetes》、容器生态圈之旅-第四章《自动化部署CICD》、容器生态圈之旅-第五章《日志收集EFK》、容器生态圈之旅-第五章《监控告警Prometheus》、容器生态圈之旅-第六章《监控告警Prometheus》、容器生态圈之旅-第七章《数据存储Ceph》。对于Mysql、Redis、Zookeeper、Kafka的掌握也是今年的要求，对了还有Go语言的深入学习(这块要求不高，今年还是围绕web深入，务必拿出原创项目)。
今年的任务很简单全面提升自我，钱不是今年的目标。人生的路很长，IT的路不会太长，我渴望站在巨人(前辈)的肩膀上成为新的巨人(前辈)。我要求自己明年的时候IT江湖有我名，紫色代表高贵，飞猪代表不屈服。我就是紫色飞猪，站在巨人的肩膀上成为新的巨人。
下半年必须在工作的同时全面提示自我！