kubernetes 官方文档
rancher 官方文档
名称 Kubernetes 源于希腊语,意为 “舵手” 或 “飞行员”。Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
- 传统部署时代: 早期,组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况,结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展,并且组织维护许多物理服务器的成本很高。
- 虚拟化部署时代: 作为解决方案,引入了虚拟化功能,它允许您在单个物理服务器的 CPU 上运行多个虚拟机(VM)。虚拟化功能允许应用程序在 VM 之间隔离,并提供安全级别,因为一个应用程序的信息不能被另一应用程序自由地访问。
因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等,所以虚拟化可以更好地利用物理服务器中的资源,并可以实现更好的可伸缩性。
每个 VM 是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。- 容器部署时代: 容器类似于 VM,但是它们具有轻量级的隔离属性,可以在应用程序之间共享操作系统(OS)。因此,容器被认为是轻量级的。容器与 VM 类似,具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离,因此可以跨云和 OS 分发进行移植。
容器是打包和运行应用程序的好方式。在生产环境中,您需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 的救援方法!Kubernetes 为您提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。例如,Kubernetes 可以轻松管理系统的 Canary 部署。
Kubernetes 为您提供:
- 服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。- 存储编排
Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。- 自动部署和回滚
您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。- 自动二进制打包
Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。- 自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。- 密钥与配置管理
Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。
- 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 的描述的时候,非常费解,什么叫做无状态应用程序,什么叫有状态?在搜索了较多资料以后,这里给出我个人的一些理解:
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旨在做一个简单干净轻量级稳定的kubernetes安装工具,能很好的支持高可用安装。 其实把一个东西做的功能强大并不难,但是做到极简且灵活可扩展就比较难。
所以在实现时就必须要遵循这些原则。
sealos特性与优势:
- 支持离线安装,工具与资源包(二进制程序 配置文件 镜像 yaml文件等)分离,这样不同版本替换不同离线包即可
- 证书延期
- 使用简单
- 支持自定义配置
- 内核负载,极其稳定,因为简单所以排查问题也极其简单
# 下载并安装sealos, sealos是个golang的二进制工具,直接下载拷贝到bin目录即可
wget https://github.com/fanux/sealos/releases/download/v3.0.1/sealos && \
chmod +x sealos && mv sealos /usr/bin
sealos 部署 K8S 也是非常方便,只需一行命令即可,但是既然使用了 Rancher 作为管理工具, Rancher 官方文档中描述到了很多针对 K8S 的便捷功能只支持由 Rancher Kubernetes Engine (RKE) 部署的 K8S ,例如证书过期定时提醒,定时备份,升级等功能,所以决定重装 K8S 集群,使用 RKE 安装 K8S 集群
我原先有安装 K8S 集群,这里需要卸载,裸机安装的同学跳过第一步即可
sealos clean --master 主机IP --node 节点IP --user root --passwd 密码
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
几个月过期 ,rancher 已经更新了2.4.0+版本 ,赶紧试试最新版本的功能
# 停止 rancher 容器
docker stop 容器名
# 对旧 rancher 创建数据容器
docker create --volumes-from stoic_sutherland --name rancher-data rancher/rancher:v2.3.3
stoic_sutherland 是我 rancher 的容器名
v2.3.3 是你的 rancher版本
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
# 查看当前目录
ls
看到备份数据压缩包已经成功
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
升级成功,访问 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 种
这里仅介绍系统服务警报,如果需要深入了解请自行查看官方文档
配置好后,点击确定
参考官方文档 Prometheus 表达式
非常简单,在工作负载的详情界面上点击添加即可
RKE 安装的 kubernetes 集群可以通过以下方式快速添加集群节点
1、选择集群
2、点击编辑配置
3、复制添加命令并在新的节点上运行
结束,是不是很简单
卸载原有 K8S
sealos clean --node 节点IP --user root --passwd 密码
在 Rancher UI 右下角下载 Rancher CLI linux 版本
上传到服务器并且解压
tar -zxvf rancher-linux-amd64-v2.4.5.tar.gz
添加环境变量
vi /etc/profile
添加下面配置
export PATH=$PATH:/root/rancherCli/rancher-v2.4.5
保存配置文件后,刷新配置
source /etc/profile
执行 rancher 命令测试 Rancher CLI 是否安装成功
点击生成 API Key
添加 Key
生成成功
测试 API Key
rancher login API访问地址 --token 刚刚生成的 Bearer Token
执行成功则表示成功
# 查看集群列表
rancher cluster ls
找到自己要克隆的集群,复制集群的 ID 或者 NAME ,替换以下命令中的
# 输入以下命令以导出集群的配置。
rancher clusters export
步骤结果:克隆群集的YAML打印到终端。
将YAML复制到剪贴板,并将其粘贴到新文件中。将文件另存为cluster-template.yml(或其他任何名称,只要具有.yml扩展名)。
如下例所示,在
Version: v3
clusters:
: # ENTER UNIQUE NAME
dockerRootDir: /var/lib/docker
enableNetworkPolicy: false
rancherKubernetesEngineConfig:
addonJobTimeout: 30
authentication:
strategy: x509
authorization: {}
bastionHost: {}
cloudProvider: {}
ignoreDockerVersion: true
对于每个nodePools部分,在
nodePools:
:
clusterId: do
controlPlane: true
etcd: true
hostnamePrefix: mark-do
nodeTemplateId: do
quantity: 1
worker: true
rancher up --file cluster-template.yml
Rancher 的流水线功能目前不满足我目前的需要,所以还是使用 Jenkins 做自动化部署。
目前的方案是在 Jenkins 上完成镜像的打包,并且推送镜像到 Docker 私服,在统一的 linux 服务器上执行 kebuctl 命令部署工作负载。
kubectl 概念
kubectl 是 kubernetes 官方提供的 kubernetes 命令行管理工具。
RKE 安装的 K8S 在宿主机上是无法运行 kubectl 命令的,需要自行安装。
设置阿里云服务器
cat < /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
在 Rancher 集群页面获取 kubectl 配置文件
将信息复制到文件中并上传到服务器 ~/.kube/config/kube.config
~/. 指的是当前登录用户目录
如果是普通用户,则是 /home/用户名
如果是 root 用户,则是 /root
之后就可以通过这个配置文件访问 K8S 集群了
测试配置 ,查看工作负载
kubectl --kubeconfig /root/kube/config/kube.config get pods
配置成功
jenkins 安装插件 Gitlab Hook Plugin 、Gitlab
搜索后安装
Jenkins 任务中运行打包镜像,部署工作负载等命令的服务器,有以下几个要求
我们的 Docker 服务由于域名和证书原因,需要不验证 https 的 X509 证书合法性,如果没有这个问题可以跳过
新建文件
vi /etc/docker/daemon.json
{
"insecure-registries" : ["你的 Docker 服务器地址"]
}
重新加载 docker 配置
systemctl reload docker
Rancher 配置 Docker 私服
选择资源 -> 密文
点击添加凭证,输入自己的 Docker 私服地址,账户密码
git 权限
服务器权限
任务配置
登录 Jenkins 服务器,点击新建任务,选择构建一个自由风格的项目
配置自己的源码地址及账户密码
配置构建触发器
点击高级,按如图配置
在 gtilab 项目页面配置,在设置中的 web 钩子页面中,将刚刚上面 jenkins 中生成的 url 和 Token 填入并生成 web钩子
生成的 Token
选择 Maven 构建
根据自己需求填写 Maven 命令和选择 pom 文件
构建后步骤选择如图插件
根据自己需求填写数据
参数解释
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<
Exec command 命令解析
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
后续只要在 master 分支提交代码或者合并分支到 master 分支,就会自动触发 jenkins 自动构建项目
yaml 解释
deployments 详解,请查看官网链接
测试
点击立即构建
查看运行日志
看到编译成功
在 Rancher 界面查看,工作负载已经部署成功
这里引用 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