目录
- kubernetes 介绍
- 本教程版本
- sealos 介绍及安装
- RKE 安装 K8S
- rancher 备份与升级
- 集群定时备份与恢复
- 工作负载
- 负载均衡
- 监控
- 通知配置
- 告警配置
- 快速添加工作负载 pod
- 快速新增/删除集群节点
- 集群克隆
- 流水线( CI/CD)
- Yaml 详解
kubernetes 介绍
官方文档
kubernetes(K8S)概念
名称 Kubernetes 源于希腊语,意为 “舵手” 或 “飞行员”。Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
服务器部署时代变迁
- 传统部署时代: 早期,组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况,结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展,并且组织维护许多物理服务器的成本很高。
- 虚拟化部署时代: 作为解决方案,引入了虚拟化功能,它允许您在单个物理服务器的 CPU 上运行多个虚拟机(VM)。虚拟化功能允许应用程序在 VM 之间隔离,并提供安全级别,因为一个应用程序的信息不能被另一应用程序自由地访问。
因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等,所以虚拟化可以更好地利用物理服务器中的资源,并可以实现更好的可伸缩性。
每个 VM 是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。- 容器部署时代: 容器类似于 VM,但是它们具有轻量级的隔离属性,可以在应用程序之间共享操作系统(OS)。因此,容器被认为是轻量级的。容器与 VM 类似,具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离,因此可以跨云和 OS 分发进行移植。
为什么需要 Kubernetes,它能做什么?
容器是打包和运行应用程序的好方式。在生产环境中,您需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 的救援方法!Kubernetes 为您提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。例如,Kubernetes 可以轻松管理系统的 Canary 部署。
Kubernetes 为您提供:
- 服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。- 存储编排
Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。- 自动部署和回滚
您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。- 自动二进制打包
Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。- 自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。- 密钥与配置管理
Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。
Pods
- Pod 是 Kubernetes 应用程序的基本执行单元,即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在 集群 上运行的进程。
- Pod 封装了应用程序容器(或者在某些情况下封装多个容器)、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。
- Pod 中的所有容器共享一个 IP 地址和端口空间,并且可以通过 localhost 互相发现。他们也能通过标准的进程间通信(如 SystemV 信号量或 POSIX 共享内存)方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同,没有 特殊配置 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。
- 在 Docker 体系的术语中,Pod 被建模为一组具有共享命名空间和共享文件系统卷 的 Docker 容器。
控制器
- 在机器人技术和自动化中,控制回路是一个非终止回路,用于调节系统状态。
- 这是一个控制环的例子:房间里的温度自动调节器。
当你设置了温度,告诉了温度自动调节器你的期望状态。房间的实际温度是当前状态。通过对设备的开关控制,温度自动调节器让其当前状态接近期望状态。- 控制器通过 apiserver 监控集群的公共状态,并致力于将当前状态转变为期望的状态。
- 控制器可以为您创建和管理多个 Pod,管理副本和上线,并在集群范围内提供自修复能力。 例如,如果一个节点失败,控制器可以在不同的节点上调度一样的替身来自动替换 Pod。
控制器包含以下几种
1、Deployment:
部署最适合用于无状态应用程序(即,当您不必维护工作负载的状态时)。由部署工作负载管理的Pod被视为独立且可处理的。如果Pod遇到中断,Kubernetes会将其删除,然后重新创建。示例应用程序将是Nginx Web服务器。
2、StatefulSets
与部署相反,当您的应用程序需要维护其身份并存储数据时,最好使用StatefulSets。应用程序将类似于Zookeeper,即需要数据库存储的应用程序。
3、DaemonSets
守护程序确保集群中的每个节点都运行一个pod副本。对于要收集日志或监视节点性能的用例,这种类似于守护程序的工作负载效果最佳。
4、Jobs
作业启动一个或多个吊舱,并确保成功终止指定数量的吊舱。与管理进行中的所需应用程序状态相反,作业最好用于完成有限任务。
5、CronJobs
CronJobs与工作相似。但是,CronJobs会按基于cron的时间表运行完毕。
我第一次看到 Deployment 的描述的时候,非常费解,什么叫做无状态应用程序,什么叫有状态?在搜索了较多资料以后,这里给出我个人的一些理解:
- 无状态应用程序:程序的每个 Pod 之间相互独立,没有依赖关系,例如:普通的信息网站前端
- 有状态应用程序:程序的每个 Pod 之间互相依赖,添加每个 Pod 的时候需要做类似数据同步之类的操作,例如: Mysql 数据库
Service(服务发现)
Kubernetes 中的服务(Service)是一种抽象概念,它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。
尽管每个 Pod 都有一个唯一的 IP 地址,但是如果没有 Service ,这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露
- ClusterIP (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。
- NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用: 从集群外部访问 Service。是 ClusterIP 的超集。
- LoadBalancer - 在当前云中创建一个外部负载均衡器(如果支持的话),并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
- ExternalName - 通过返回带有该名称的 CNAME 记录,使用任意名称(由 spec 中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。
Service 匹配一组 Pod 是使用 标签(Label)和选择器(Selector), 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对。
本教程版本
Rancher 版本 v2.4.5
Kubernetes 版本: v1.18.6
sealos 介绍及安装
sealos 介绍
sealos旨在做一个简单干净轻量级稳定的kubernetes安装工具,能很好的支持高可用安装。 其实把一个东西做的功能强大并不难,但是做到极简且灵活可扩展就比较难。
所以在实现时就必须要遵循这些原则。
sealos特性与优势:
- 支持离线安装,工具与资源包(二进制程序 配置文件 镜像 yaml文件等)分离,这样不同版本替换不同离线包即可
- 证书延期
- 使用简单
- 支持自定义配置
- 内核负载,极其稳定,因为简单所以排查问题也极其简单
部署 sealos
# 下载并安装sealos, sealos是个golang的二进制工具,直接下载拷贝到bin目录即可
wget https://github.com/fanux/sealos/releases/download/v3.0.1/sealos && \
chmod +x sealos && mv sealos /usr/bin
- 1
- 2
- 3
不选择 sealos 部署 K8S 的原因
sealos 部署 K8S 也是非常方便,只需一行命令即可,但是既然使用了 Rancher 作为管理工具, Rancher 官方文档中描述到了很多针对 K8S 的便捷功能只支持由 Rancher Kubernetes Engine (RKE) 部署的 K8S ,例如证书过期定时提醒,定时备份,升级等功能,所以决定重装 K8S 集群,使用 RKE 安装 K8S 集群
RKE 安装 K8S
我原先有安装 K8S 集群,这里需要卸载,裸机安装的同学跳过第一步即可
- 卸载原有 K8S
sealos clean --master 主机IP --node 节点IP --user root --passwd 密码
- 1
2. 关闭selinux
#闭swap分区【虚拟内存】并且永久关闭虚拟内存
swapoff -a && sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
#关闭selinux
setenforce 0 && sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
- 1
- 2
- 3
- 4
- 5
- 登录 Rancher ,创建 K8S 集群
- 选择自定义
- 输入名称,选择 K8S 版本,其他默认,点击下一步
- 勾选 etc 和 control ,复制命令到主机上运行
- 仅选择 worker ,复制命令到节点服务器上运行
- 等待 K8S 部署成功以后可以看到 K8S 集群已经是 Active 状态,版本是 1.18.6
rancher 备份与升级
几个月过期 ,rancher 已经更新了2.4.0+版本 ,赶紧试试最新版本的功能
备份
- 备份现有容器数据
# 停止 rancher 容器
docker stop 容器名
# 对旧 rancher 创建数据容器
docker create --volumes-from stoic_sutherland --name rancher-data rancher/rancher:v2.3.3
- 1
- 2
- 3
- 4
stoic_sutherland 是我 rancher 的容器名
v2.3.3 是你的 rancher版本
- 创建一个备用压缩包
如果升级期间出现问题,则此tarball将用作回滚点。使用以下命令,创建压缩包
docker run --volumes-from rancher-data -v $PWD:/backup busybox tar zcvf /backup/rancher-data-backup-v2.3.3-20200716.tar.gz /var/lib/rancher
- 1
# 查看当前目录
ls
- 1
- 2
看到备份数据压缩包已经成功
升级 Rancher
3.部署
根据自己当时最新版本号修改命令最后的版本号
# 拉取最新镜像
docker pull rancher/rancher:v2.4.5
# 运行容器,这里 rancher 是使用默认的自签名证书来部署,如果有需求请自行根据官网文档修改命令
docker run -d --volumes-from rancher-data \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
rancher/rancher:v2.4.5
- 1
- 2
- 3
- 4
- 5
- 6
- 7
升级成功,访问 rancher
集群定时备份与恢复
集群定时备份
集群定时备份
rancher v2.2.0 以后开始支持对于 RKE 安装 K8S 集群定时快照备份功能
这里介绍 rancher v2.4.0+ 版本的快照功能使用
这里可以配置定时备份 etcd 的频率(小时)和备份数,备份的文件路径在 /opt/rke/etcd-snapshots 下
查看备份及备份文件位置
在工具中的备份,可以查看现有所有备份
备份文件迁移
集群恢复
选择对应时间戳的备份数据,就可以将集群恢复,由于快照中现已包含Kubernetes版本,因此可以将群集还原到先前的Kubernetes版本。
如果需要快照中的集群,则快照的多个组件允许您从以下选项中进行选择:
Restore just the etcd contents:此还原类似于在v2.4.0之前的Rancher中还原快照。
恢复etcd和Kubernetes版本:如果Kubernetes升级是您的集群出现故障的原因,并且您尚未进行任何集群配置更改,则应使用此选项。
恢复etcd,Kubernetes版本和集群配置:如果在升级时同时更改了Kubernetes版本和集群配置,则应使用此选项。
工作负载
部署工作负载
点击工作负载,点击部署服务
工作负载有多种类型
Kubernetes将工作负载分为不同的类型。Kubernetes支持的最受欢迎的类型是:
1、Deployment:
部署最适合用于无状态应用程序(即,当您不必维护工作负载的状态时)。由部署工作负载管理的Pod被视为独立且可处理的。如果Pod遇到中断,Kubernetes会将其删除,然后重新创建。示例应用程序将是Nginx Web服务器。
2、StatefulSets
与部署相反,当您的应用程序需要维护其身份并存储数据时,最好使用StatefulSets。应用程序将类似于Zookeeper,即需要数据库存储的应用程序。
3、DaemonSets
守护程序确保集群中的每个节点都运行一个pod副本。对于要收集日志或监视节点性能的用例,这种类似于守护程序的工作负载效果最佳。
4、Jobs
作业启动一个或多个吊舱,并确保成功终止指定数量的吊舱。与管理进行中的所需应用程序状态相反,作业最好用于完成有限任务。
5、CronJobs
CronJobs与工作相似。但是,CronJobs会按基于cron的时间表运行完毕。
填入 docker 镜像名
这里的镜像名称可以指定获取镜像的服务器,可以指定 dockerhub 或者私服(例如registry.gitlab.com/user/path/image:tag),如果不指定默认从 Docker Hub 上获取镜像,如果没有指定 tag,则默认使用最新镜像。
配置端口映射
这里网络模式写的很清楚,不再赘述
打开高级选项
因为笔者这里使用的是服务器上的本地镜像,所以将镜像拉取策略改为不存在则拉取
点击启动,稍等片刻工作负载就启动完成
升级工作负载
1、编辑负载
2、更新 docker 镜像版本
3、查看默认升级策略是否需要修改
4、点击升级
回滚工作负载
1、从“ 全局”视图中,打开运行要回滚的工作负载的项目。
2、找到您要回滚的工作负载,然后选择“ 垂直⋮(…)>回滚”。
3、选择要回滚的修订版。单击回滚。
负载均衡
rancher 的负载均衡分 2 种
四层负载均衡
四层负载均衡工作在 OSI 模型的传输层,由于在传输层,只有 TCP/UDP 协议,这两种协议中除了包含源 IP、目标 IP 以外,还包含源端口号及目的端口号。
四层负载均衡服务器在接受到客户端请求后,以后通过修改数据包的地址信息( IP+端口号 )将流量转发到应用服务器。
七层负载均衡
七层负载均衡工作在 OSI 模型的应用层,应用层协议较多,常用 HTTP、Radius、DNS 等。七层负载就可以基于这些协议来负载。
通常,底层云提供程序支持第4层负载平衡器,因此,当在裸机服务器和vSphere群集上部署RKE群集时,不支持第4层负载平衡器。但是,可以使用单个全局托管的配置映射在NGINX或第三方入口上公开服务。
第7层负载平衡器(或入口控制器)支持基于主机和路径的负载平衡以及SSL终止。第7层负载平衡器仅转发HTTP和HTTPS通信,因此它们仅侦听端口80和443。亚马逊和谷歌等云提供商均支持第7层负载均衡器。另外,RKE集群部署Nginx入口控制器。
负载均衡参照这篇文章
Rancher 2.x 负载均衡配置及使用
监控
rancher 配置的监控使用的是开源监控解决方案 Prometheus集成来监视集群节点,Kubernetes组件和软件部署的状态和过程。
监控范围
使用Prometheus,您可以在群集级别和项目级别监视Rancher 。对于每个启用了监视的群集和项目,Rancher都会部署一个Prometheus服务器。
群集监控可让您查看Kubernetes群集的运行状况。Prometheus从下面的群集组件中收集指标,您可以在图形和图表中查看这些指标。
- Kubernetes控制平面
- etcd数据库
- 所有节点(包括工作负载)
通过项目监视,可以查看在给定项目中运行的Pod的状态。Prometheus从项目的已部署HTTP和TCP / UDP工作负载中收集指标。
集群监控
进入集群页面
在没有开启集群监控时,此处会有个开启监控按钮
根据需要调整监控数据,这里直接默认
等一段时间监控组件启动成功后,会在集群仪表盘界面多出几个监控节点
项目监控
在工作负载界面点击监控,使用默认配置,点击确定
等项目监控组件启动完成后,可以在 Pod 页面监控所有 pod 的性能
通知配置
通知程序是通知您警报事件的服务。您可以配置通知程序,以将警报通知发送给最适合采取纠正措施的人员。
Rancher与各种流行的IT服务集成在一起,包括:
- Slack:向您的Slack频道发送警报通知。
- 电子邮件:选择警报通知的电子邮件收件人。
- PagerDuty:通过电话,短信或个人电子邮件将通知发送给员工。
- WebHooks:用警报通知更新网页。
- 微信:向您的企业微信联系人发送警报通知。
进入集群仪表盘
在导航栏中的工具下拉框中选择通知
点击添加通知
根据自己的需要选择通知方式并填写相关信息
点击测试通过后点击确定,完成通知配置
告警配置
告警范围
警报的范围可以在集群级别或项目级别设置。
在集群级别,Rancher监视Kubernetes集群中的组件,并向您发送与以下内容有关的警报:
- 节点的状态。
- 管理Kubernetes集群的系统服务。
- 来自特定系统服务的资源事件。
- Prometheus表达式越过阈值
集群告警配置
在集群界面导航栏选择工具 -》 告警
添加告警组
告警类型有以下 5 种
- 系统服务警报
该警报类型监视影响Kubernetes主组件之一的事件,无论它发生在哪个节点上。 - 资源时间警报
此警报类型监视从资源类型引发的特定事件。 - 节点警报
此警报类型监视特定节点上发生的事件。 - 节点选择器警报
此警报类型监视在标记有标签的任何节点上发生的事件 - Prometheus 表达式警告
此警报类型监视Prometheus表达式查询中的重载,启用监视后将可用。
这里仅介绍系统服务警报,如果需要深入了解请自行查看官方文档
配置好后,点击确定
Prometheus 表达式
参考官方文档 Prometheus 表达式
快速添加工作负载 pod
非常简单,在工作负载的详情界面上点击添加即可
快速新增/删除集群节点
快速新增集群节点
RKE 安装的 kubernetes 集群可以通过以下方式快速添加集群节点
1、选择集群
2、点击编辑配置
3、复制添加命令并在新的节点上运行
结束,是不是很简单
快速删除集群节点
卸载原有 K8S
sealos clean --node 节点IP --user root --passwd 密码
- 1
集群克隆
支持集群类型
前提条件
安装 Rancher CLI
在 Rancher UI 右下角下载 Rancher CLI linux 版本
上传到服务器并且解压
tar -zxvf rancher-linux-amd64-v2.4.5.tar.gz
- 1
添加环境变量
vi /etc/profile
添加下面配置
export PATH=$PATH:/root/rancherCli/rancher-v2.4.5
- 1
- 2
- 3
- 4
保存配置文件后,刷新配置
source /etc/profile
- 1
执行 rancher 命令测试 Rancher CLI 是否安装成功
生成 API Key
点击生成 API Key添加 Key
生成成功
测试 API Key
rancher login API访问地址 --token 刚刚生成的 Bearer Token
- 1
执行成功则表示成功
克隆集群
导出集群配置
# 查看集群列表
rancher cluster ls
- 1
- 2
找到自己要克隆的集群,复制集群的 ID 或者 NAME ,替换以下命令中的 <RESOURCE_ID>
# 输入以下命令以导出集群的配置。
rancher clusters export <RESOURCE_ID>
- 1
- 2
步骤结果:克隆群集的YAML打印到终端。
将YAML复制到剪贴板,并将其粘贴到新文件中。将文件另存为cluster-template.yml(或其他任何名称,只要具有.yml扩展名)。
修改集群配置
如下例所示,在<CLUSTER_NAME>占位符处,用唯一名称(<CLUSTER_NAME>)替换原始群集的名称。如果克隆的群集具有重复名称,则该群集将无法成功配置。
Version: v3
clusters:
<CLUSTER_NAME>: # ENTER UNIQUE NAME
dockerRootDir: /var/lib/docker
enableNetworkPolicy: false
rancherKubernetesEngineConfig:
addonJobTimeout: 30
authentication:
strategy: x509
authorization: {}
bastionHost: {}
cloudProvider: {}
ignoreDockerVersion: true
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
对于每个nodePools部分,在<NODEPOOL_NAME>占位符处用唯一名称替换原始节点池名称。如果克隆的群集具有重复的节点池名称,则该群集将无法成功配置。
nodePools:
<NODEPOOL_NAME>:
clusterId: do
controlPlane: true
etcd: true
hostnamePrefix: mark-do
nodeTemplateId: do
quantity: 1
worker: true
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
启动克隆的集群
rancher up --file cluster-template.yml
- 1
流水线( CI/CD)
Rancher 的流水线功能目前不满足我目前的需要,所以还是使用 Jenkins 做自动化部署。
目前的方案是在 Jenkins 上完成镜像的打包,并且推送镜像到 Docker 私服,在统一的 linux 服务器上执行 kebuctl 命令部署工作负载。
kubectl 安装
kubectl 概念
kubectl 是 kubernetes 官方提供的 kubernetes 命令行管理工具。
RKE 安装的 K8S 在宿主机上是无法运行 kubectl 命令的,需要自行安装。
设置阿里云服务器
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
安装 kubectl
yum install -y kubectl
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
kubectl 配置
在 Rancher 集群页面获取 kubectl 配置文件
将信息复制到文件中并上传到服务器 ~/.kube/config/kube.config
~/. 指的是当前登录用户目录
如果是普通用户,则是 /home/用户名
如果是 root 用户,则是 /root
之后就可以通过这个配置文件访问 K8S 集群了
测试配置 ,查看工作负载
kubectl --kubeconfig /root/kube/config/kube.config get pods
- 1
- 2
- 3
配置成功
Jenkins 流水线
Jenkins 插件安装
jenkins 安装插件 Gitlab Hook Plugin 、Gitlab
搜索后安装
服务器环境要求
Jenkins 任务中运行打包镜像,部署工作负载等命令的服务器,有以下几个要求
- List item
Docker 私服配置
我们的 Docker 服务由于域名和证书原因,需要不验证 https 的 X509 证书合法性,如果没有这个问题可以跳过
新建文件
vi /etc/docker/daemon.json
{
"insecure-registries" : ["你的 Docker 服务器地址"]
}
重新加载 docker 配置
systemctl reload docker
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Rancher 配置 Docker 私服
选择资源 -> 密文
点击添加凭证,输入自己的 Docker 私服地址,账户密码
配置权限
git 权限
服务器权限
新建任务
任务配置
登录 Jenkins 服务器,点击新建任务,选择构建一个自由风格的项目
配置自己的源码地址及账户密码
配置构建触发器
点击高级,按如图配置
在 gtilab 项目页面配置,在设置中的 web 钩子页面中,将刚刚上面 jenkins 中生成的 url 和 Token 填入并生成 web钩子
生成的 Token
选择 Maven 构建
根据自己需求填写 Maven 命令和选择 pom 文件
构建后步骤选择如图插件
根据自己需求填写数据
参数解释
- Source files
要上载到服务器的文件。支持通配符,例如。* * / *。 - Remove prefi
删除前缀,你通常不希望在服务器上创建这些文件的完整路径。
例如,如果源文件是target/deployment/images/**/,那么您可能希望将前缀删除为target/deployment,这将在远程目录下创建images文件夹,而不是target/deployment - Remote directory
上传的目标远程文件夹 - Exec command
执行的具体命令
Exec command 具体如下
这里不用完全照搬命令,每个人的项目打包后结构不同,可以根据自己情况修改
cd project/ecm2
unzip -u -o ecm-admin-0.0.1-SNAPSHOT-package.zip
if [ ! -f "dockerfile" ];then echo "文件不存在";else rm -f dockerfile; fi
touch dockerfile
cat >> dockerfile<<EOF
From frolvlad/alpine-glibc
#这里自行修改项目名
MAINTAINER ecm
#创建文件夹,这里自行修改项目名
RUN mkdir /usr/local/ecm
#这里自行修改项目名
WORKDIR /usr/local/ecm
#拷贝项目文件夹,这里自行修改,就是上传到服务器的那个文件夹名
COPY ecm-admin-0.0.1-SNAPSHOT /usr/local/ecm/ecm-admin-0.0.1-SNAPSHOT
#添加jre8环境
RUN mkdir /usr/local/java
ADD server-jre-8u202-linux-x64.tar.gz /usr/local/java/
#对外接口,根据自己项目端口自行修改
EXPOSE 8765
EXPOSE 9997
# 项目名自行修改
VOLUME /usr/local/tlsProxy/log/
#授予运行权限,项目路径及名称自行修改
RUN chmod -R +x /usr/local/ecm/ecm-admin-0.0.1-SNAPSHOT/bin
#设置jre8环境
ENV JAVA_HOME /usr/local/java/jdk1.8.0_202
ENV PATH ${PATH}:${JAVA_HOME}/bin
CMD ["java","-version"]
#运行服务,项目路径及名称自行修改,这里的 sh 指的是上面的 start.sh
ENTRYPOINT ["nohup","/usr/local/ecm/ecm-admin-0.0.1-SNAPSHOT/bin/ecm-admin.sh"]
EOF
docker build -t 私服地址/ecm:1.1 .
docker login -u你的账户 -p你的密码 Docker私服地址
docker push 私服地址/ecm:1.1
kubectl --kubeconfig /root/kube/config/kube.config delete -f /root/project/ecm2/deployment.yml --ignore-not-found=true
sleep 5
kubectl --kubeconfig /root/kube/config/kube.config create -f /root/project/ecm2/deployment.yml
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
Exec command 命令解析
- unzip -u -o ecm-admin-0.0.1-SNAPSHOT-package.zip 解压代码压缩文件夹
- if [ ! -f “dockerfile” ];then echo “文件不存在”;else rm -f dockerfile; fi touch dockerfile cat >> dockerfile<<EOF 生成 dockerfile
- docker build -t 私服地址/ecm:1.1 . 编译镜像
- docker login -u你的账户 -p你的密码 Docker私服地址 登录到 Docker 私服
- docker push 私服地址/ecm:1.1 推送镜像到 Docker 私服
- kubectl --kubeconfig /root/kube/config/kube.config delete -f /root/project/ecm2/deployment.yml --ignore-not-found=true 根据配置文件删除原有工作负载
- sleep 5 等待5秒
- kubectl --kubeconfig /root/kube/config/kube.config create -f /root/project/ecm2/deployment.yml根据配置文件部署新的工作负载
deployment.yml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: ecm
labels:
app: ecm
spec:
replicas: 1
selector:
matchLabels:
app: ecm
template:
metadata:
labels:
app: ecm
spec:
containers:
- name: ecm
image: 你的私服地址/ecm:1.1
ports:
- containerPort: 80
protocol: TCP
imagePullPolicy: Always
imagePullSecrets:
- name: dc-pm895
---
kind: Service
apiVersion: v1
metadata:
labels:
app: ecm-service
name: ecm-service
namespace: default
spec:
type: NodePort
ports:
- port: 8765
targetPort: 8765
nodePort: 30149
selector:
app: ecm
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
后续只要在 master 分支提交代码或者合并分支到 master 分支,就会自动触发 jenkins 自动构建项目
yaml 解释
- yaml 中的 ecm 是我的项目名,根据自己项目进行修改,要保持一致
- image: 你的私服地址/ecm:1.1 你的镜像名,如果没有私服则直接改为 ecm:1.1 根据自己情况修改
- imagePullSecrets:- name: dc-pm895 这里是 Docker 私服的密文名称,可以在上面的 Docker 私服配置章节中查看,如果没有私服则无需配置这项
- imagePullPolicy: Always 镜像的拉取策略,1、 Always 总是拉取 2、 IfNotPresent 不存在则拉取 3、Never 不拉取
- ports:nodePort 对外开放的端口信息
deployments 详解,请查看官网链接
测试
点击立即构建
查看运行日志
看到编译成功
在 Rancher 界面查看,工作负载已经部署成功
Yaml 详解
这里引用 cnblob 的一个 yaml 详解 ,原文地址
#test-pod
apiVersion: v1 #指定api版本,此值必须在kubectl apiversion中
kind: Pod #指定创建资源的角色/类型
metadata: #资源的元数据/属性
name: test-pod #资源的名字,在同一个namespace中必须唯一
labels: #设定资源的标签
k8s-app: apache
version: v1
kubernetes.io/cluster-service: "true"
annotations: #自定义注解列表
- name: String #自定义注解名字
spec: #specification of the resource content 指定该资源的内容
restartPolicy: Always #表明该容器一直运行,默认k8s的策略,在此容器退出后,会立即创建一个相同的容器
nodeSelector: #节点选择,先给主机打标签kubectl label nodes kube-node1 zone=node1
zone: node1
containers:
- name: test-pod #容器的名字
image: 10.192.21.18:5000/test/chat:latest #容器使用的镜像地址
imagePullPolicy: Never #三个选择Always、Never、IfNotPresent,每次启动时检查和更新(从registery)images的策略,
# Always,每次都检查
# Never,每次都不检查(不管本地是否有)
# IfNotPresent,如果本地有就不检查,如果没有就拉取
command: ['sh'] #启动容器的运行命令,将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT
args: ["$(str)"] #启动容器的命令参数,对应Dockerfile中CMD参数
env: #指定容器中的环境变量
- name: str #变量的名字
value: "/etc/run.sh" #变量的值
resources: #资源管理
requests: #容器运行时,最低资源需求,也就是说最少需要多少资源容器才能正常运行
cpu: 0.1 #CPU资源(核数),两种方式,浮点数或者是整数+m,0.1=100m,最少值为0.001核(1m)
memory: 32Mi #内存使用量
limits: #资源限制
cpu: 0.5
memory: 1000Mi
ports:
- containerPort: 80 #容器开发对外的端口
name: httpd #名称
protocol: TCP
livenessProbe: #pod内容器健康检查的设置
httpGet: #通过httpget检查健康,返回200-399之间,则认为容器正常
path: / #URI地址
port: 80
#host: 127.0.0.1 #主机地址
scheme: HTTP
initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始
timeoutSeconds: 5 #检测的超时时间
periodSeconds: 15 #检查间隔时间
#也可以用这种方法
#exec: 执行命令的方法进行监测,如果其退出码不为0,则认为容器正常
# command:
# - cat
# - /tmp/health
#也可以用这种方法
#tcpSocket: //通过tcpSocket检查健康
# port: number
lifecycle: #生命周期管理
postStart: #容器运行之前运行的任务
exec:
command:
- 'sh'
- 'yum upgrade -y'
preStop:#容器关闭之前运行的任务
exec:
command: ['service httpd stop']
volumeMounts: #挂载持久存储卷
- name: volume #挂载设备的名字,与volumes[*].name 需要对应
mountPath: /data #挂载到容器的某个路径下
readOnly: True
volumes: #定义一组挂载设备
- name: volume #定义一个挂载设备的名字
#meptyDir: {}
hostPath:
path: /opt #挂载设备类型为hostPath,路径为宿主机下的/opt,这里设备类型支持很多种
#nfs