怎么制作做网站,创做阿里巴巴网站流程,中国采购网,移动终端的网站文章目录 一、k3s简介二、快速搭建1.控制平面2.镜像加速 Pod容器集1.创建和管理pod Deployment(部署)与ReplicaSet(副本集)滚动更新 Service命名空间YAML语法管理对象常用命令缩写YAML规范 声明式配置对象标签选择器 容器运行时接口(CRI)与镜像导入导出容器运行时接口(CRI) 金丝… 文章目录 一、k3s简介二、快速搭建1.控制平面2.镜像加速 Pod容器集1.创建和管理pod Deployment(部署)与ReplicaSet(副本集)滚动更新 Service命名空间YAML语法管理对象常用命令缩写YAML规范 声明式配置对象标签选择器 容器运行时接口(CRI)与镜像导入导出容器运行时接口(CRI) 金丝雀发布创建Canary Deployment局限性 运行有状态应用(MySQL数据库)存储创建Mysql配置环境变量hostPath卷 ConfigMap与SecretConfigMapConfigMap用法Secret 卷(Volume)常见的卷类型后端存储 临时卷(EV)临时卷(Ephemeral Volume)emptyDir configMap卷和secret卷持久卷(PV)与持久卷声明(PVC)持久卷(PV)和持久卷声明(PVC)创建持久卷PV创建持久卷声明(PVC)使用PVC作为卷绑定访问模式卷的状态卷模式 存储类(StorageClass)创建持久卷(PV)存储类(StorageClass)Local Path Provisioner卷绑定模式回收策略Reclaim Policy StatefulSet(有状态应用集)StatefulSet创建StatefulSet稳定的存储Pod 标识部署和扩缩保证Headless Service(无头服务)无头服务Headless Services 稳定的网络 ID Mysql主从复制Mysql主从复制初始化容器(Init Containers)边车Sidecar 客户端连接 Port-forward端口转发网络访问 Helm安装MySQL机群Helm简介与安装三大概念Helm部署MySQL集群 部署若依(RuoYi-Vue) 一、k3s简介
为什么使用K3s K3s 是一个轻量级的、完全兼容的 Kubernetes 发行版本。非常适合初学者。 K3s将所有 Kubernetes 控制平面组件都封装在单个二进制文件和进程中文件大小 100M占用资源更小且包含了kubernetes运行所需要的部分外部依赖和本地存储提供 程序。 K3s提供了离线安装包安装起来非常方便可以避免安装过程中遇到各种网络资源访问 问题。 K3s特别适用于边缘计算、物联网、嵌入式和ARM移动端场景
二、快速搭建
1.控制平面
INSTALL_K3S_SKIP_DOWNLOADtrue ./install.sl
查看
watch -n 1 kubectl get node
记住token 使节点加入控制平面
cat /var/lib/rancher/k3s/server/node-token工作节点
INSTALL_K3S_SKIP_DOWNLOADtrue \
K3S_URLhttps://192.168.1.55:6443 \
K3S_TOKENxxx \
./install.sh2.镜像加速
由于kubernetes从V1.24版本开始默认使用 containerd 需要修改containerd的 配置文件才能让Pod的镜像使用镜像加速器。 配置文件路径一般为 /etc/containerd/config,toml详见阿里云镜像加速
查看containerd的一个进程
ps -ef | grep containerdk3s会自动生成一个目录 K3s 会自动生成containerd的配置文件/var/lib/rancher/k3s/agent/etc/containerd/config.toml, 不要直接修改这个文件k3s重启后修改会丢失。 为了简化配置K3s 通过/etc/rancher/k3s/registries.yaml文件来配置镜像仓库K3s 会在启动时检查这个文件是否存在。 我们需要在每个节点上新建/etc/rancher/k3s/registries.yaml文件配置内容如下:
mirrors: docker.io: endpoint:- 地址然后systemctl restasrt k3s重启k3s 然后再查看/etc/rancher/k3s/registries.yaml
配置其他工作节点**(可能需要创建)**
cd /etc/rancher/k3s/
vim registries.yaml重启node节点systemctl restart k3s-agent
Pod容器集
Pod 是包含一个或多个容器的容器组是 Kubernetes 中创建和管理的最小对象。 Pod 有以下特点:
Pod是kubernetes中最小的调度单位 (原子单元)Kubernetes直接管理Pod而不是容 器。同一个Pod中的容器总是会被自动安排到集群中的同一节点 (物理机或虚拟机)上并且 一起调度Pod可以理解为运行特定应用的“逻辑主机”这些容器共享存储、网络和配置声明(如资 源限制)。每个 Pod 有唯一的IP 地址。IP地址分配给Pod在同一个 Pod 内所有容器共享一个 IP 地址和端口空间Pod 内的容器可以使用locathost互相通信
例如你可能有一个容器为共享卷中的文件提供 Web 服务器支持以及一个单独的“边 车(sidercar)”容器负责从远端更新这些文件如下图所示:
1.创建和管理pod
基于docker基础 会docker一点即通
创建nginx
kubectl run mynginx --imagenginx:1.22
查看pod
kubectl get pod
查看日志
kubectl logs -f mynginx
查看pod详细信息
kubectl describe pod mynginx
查看pods详细信息
kubectl get pod -owide
可以自行curl访问
进入pod
kubectl exec -it mynginx -- /bin/bash一次性pod
kubectl run my-busybox --imagebusybox -it --rm
删除pod
kubectl delete pod mynginxDeployment(部署)与ReplicaSet(副本集)
Deployment是对ReplicaSet和Pod更高级的抽象 它使Pod拥有多副本自愈扩缩容、滚动升级等能力。
ReplicaSet(副本集)是一个Pod的集合 它可以设置运行Pod的数量确保任何时间都有指定数量的 Pod 副本在运行 通常我们不直接使用ReplicaSet而是在Deployment中声明。
创建Deployment 容量为3
kubectl create deployment nginx-deploy --imagenginx:1.22 --replicas3
查看Deployment可以缩写
kubectl get deploy实际上 并不是deployment创建的pod 而是通过ReplicaSet控制副本的数量 deployment只是声明可能比较抽象
可以查看replicaset对应关系
kubectl get replicaSet可以删除pod测试 是具备自愈能力的
也可以缩放副本
先watch实时查看
kubectl get replicaSet --watch再开一个窗口
kubectl scale deploy nginx-deply --replicas5
kubectl scale deploy nginx-deply --replicas3也可以自动缩放
#自动缩放 维持cpu负载在75%以下
kubectl autoscale deployment/nginx-auto --min3 --max10 --cpu-percent75
#查看自动缩放
kubectl get hpa
#删除自动缩放
kubectl delete hpa nginx-deployment自动缩放 自动缩放通过增加和减少副本的数量以保持所有 Pod 的平均 CPU 利用率不超过75% 自动伸缩需要声明Pod的资源限制同时使用 Metrics Server 服务(K3s默认已安装) 本例仅用来说明 kubectl autoscale 命令的使用完整示例参考: HPA演示 滚动更新
打印详情
kubectl get deploy -owide可以使用set命令来更新pod
先watch实时查看ReplicaSet可以缩写rs
kubectl get rs --watchkubectl set image deploy/nginx-deploy nginxnginx:1.23可以自行体验理解上下线顺序
也可以回滚
查看部署版本
kubectl rollout history deploy/nginx-deploy有2个版本
可以使用revision查看版本详情 kubectl rollout history deploy/nginx-deploy --revision1
进行回滚
kubectl rollout undo deploy/nginx-deploy --to-revision1可以使用实时rs观察变化
Service
Service将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法 Service为一组 Pod 提供相同的 DNS 名并且在它们之间进行负载均衡。 Kubernetes 为 Pod 提供分配了IP 地址但IP地址可能会发生变化。 集群内的容器可以通过service名称访问服务而不需要担心Pod的IP发生变化
Kubernetes Service 定义了这样一种抽象: 逻辑上的一组可以互相替换的 Pod通常称为微服务 Service 对应的 Pod 集合通常是通过选择算符来确定的。 举个例子在一个Service中运行了3个nginx的副本。这些副本是可互换的我们不需要 关心它们调用了哪个nginx也不需要关注 Pod的运行状态只需要调用这个服务就可以了。
我们可以将之前的deploy公开为service
向外公开8080 向pod指定80
kubectl expose deploy/nginx-deploy --namenginx-service --port8080 --target-port80
查看service
kubectl get service
service之间是有负载均衡的 通过service名称
可以启动一个临时的pod测试
kubectl run test -it --imagenginx:1.22 --rm --bash
curl测试
查看这个service
kubectl describe service nginx-service将service公开到哪 如果要向外网指定端口 要指定service的类型 前面用的是ClusterlP
ServiceType 取值
ClusterlP:将服务公开在集群内部。kubernetes会给服务分配一个集群内部的IP集 群内的所有主机都可以通过这个Cluster-IP访问服务。集群内部的Pod可以通过service 名称访问服务NodePort: 通过每个节点的主机IP 和静态端口 (NodePort) 暴露服务。 集群的外部主 机可以使用节点IP和NodePort访问服务。ExternalName:将集群外部的网络引入集群内部LoadBalancer: 使用云提供商的负载均衡器向外部暴露服务
在创建一个service
kubectl expose deploy/nginx-deploy --namenginx-outside --typeNodePort --port8081 --target-port80
查看分配的port进行访问
kubectl get service总结service 命名空间
命名空间(Namespace) 是一种资源隔离机制将同一集群中的资源划分为相互隔离的组 命名空间可以在多个用户之间划分集群资源 (通过资源配额)
例如我们可以设置开发、测试、生产等多个命名空间
同一命名空间内的资源名称要唯一但跨命名空间时没有这个要求 命名空间作用域仅针对带有名字空间的对象例如 Deployment、Service 等。 这种作用域对集群访问的对象不适用例如 StorageClass、Node、PersistentVolume等。
查看命名空间
kubectl get namespaceKubernetes 会创建四个初始命名空间:
default 默认的命名空间不可删除未指定命名空间的对象都会被分配到default 中。kube-system Kubernetes 系统对象(控制平面和Node组件)所使用的命名空间kube-public 自动创建的公共命名空间所有用户(包括未经过身份验证的用户)都 可以读取它。通常我们约定将整个集群中公用的可见和可读的资源放在这个空间中kube-node-lease 租约 (Lease) 对象使用的命名空间。每个节点都有一个关联的 lease 对象lease 是一种轻量级资源。lease对象通过发送心跳检测集群中的每个节 点是否发生故障。使用 kubectl get lease -A 查看 lease 对象
创建新的namespace(可以缩写ns)
kubectl create ns develop
运行pod时加入ns
kubectl run nginx --imagenginx:1.22 -ndevelop
查看指定命名空间下的pod
kubectl get pod -ndevelop
可以设置默认的命名空间为develop
kubectl config set-context ${kubectl config current-context} --namespacedevelop
kubectl get pod
删除ns会删除所有内容
kubectl delete ns develop
kubectl get nsYAML语法
管理对象
命令行指令 例如使用 kubectl命令来创建和管理 Kubernetes 对象 命令行就好比口头传达简单、快速、高效。 但它功能有限不适合复杂场景操作不容易追溯 多用于开发和调试
声明式配置 kubernetes使用yaml文件来描述 Kubernetes 对象 声明式配置就好比申请表学习难度大且配置麻烦 好处是操作留痕适合操作复杂的对象多用于生产
常用命令缩写 YAML规范
缩进代表上下级关系缩进时不允许使用Tab键只允许使用空格通常缩进2个空格:键值对后面必须有空格-列表后面必须有空格[ ]数组#注释|多行文本块---表示文档的开始多用于分割多个资源对象
示例
声明式配置对象
在创建的 Kubernetes 对象所对应的 yaml文件中需要配置的字段如下:
apiversion - Kubernetes API的版本kind -对象类别例如Pod、Deployment、Service、ReplicaSet等retadeta- 描述对象的元数据包括一个 name 字符串、UID 和可选的 namespacespee-对象的配置
掌握程度
不要求自己会写找模版能看懂会修改能排错 官方模板https://kubernetes.io/zh-cn/docs/reference/kubectl/cheatsheet/ 模板示例
apiVersion: v1
kind: Pod
metadata:name: nginx
spec:containers:- name: nginximage: nginx:1.22ports:- containerPort: 80运行 kubectl apply -f my-pod.yaml
标签
标签 (Labels) 是附加到对象 (比如 Pod) 上的键值对用于补充对象的描述信息 标签使用户能够以松散的方式管理对象映射而无需客户端存储这些映射。 由于一个集群中可能管理成千上万个容器我们可以使用标签高效的进行选择和操作容器 集合。 https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/
键的格式:
前缀(可选)/名称(必须)
有效名称和值:
必须为 63 个字符或更少 (可以为空)如果不为空必须以字母数字字符 ([a-z0-9A-Z]) 开头和结尾包含破折号一、下划线 、点和字母或数字
例子
apiVersion: v1
kind: Pod
metadata:name: label-demolabels:environment: productionapp: nginx
spec:containers:- name: nginximage: nginx:1.22ports:- containerPort: 80运行 kubectl apply -f lable-pod.yaml
查看lable kubectl get pod --show-albles
过滤 kubectl get pod -l app-nginx 如果有多个用,分割
选择器
标签选择器 可以识别一组对象。标签不支持唯一性 标签选择器最常见的用法是为Service选择一组Pod作为后端 Service配置模版
apiVersion: v1
kind: Service
metadata:name: my-service
spec:type: NodePortselector:app: nginxports:# 默认情况下为了方便起见targetPort 被设置为与 port 字段相同的值。- port: 80targetPort: 80# 可选字段# 默认情况下为了方便起见Kubernetes 控制平面会从某个范围内分配一个端口号#默认30000-32767nodePort: 30007运行
kubectl apply -f my-service.yaml
查看
kubectl get svc
查看详情
kubectl describe svc/my-service也可以过滤标签
kubectl get pod -l appnginx -owide
目前支持两种类型的选择运算基于等值的和基于集合的 多个选择条件使用逗号分隔相当于**And()**运算。
等值选择
容器运行时接口(CRI)与镜像导入导出
容器运行时接口(CRI)
Kubelet运行在每个节点(Node)上,用于管理和维护Pod和容器的状态。 容器运行时接口 (CRI)是kubelet 和容器运行时之间通信的主要协议。它将 Kubelet 与 容器运行时解耦理论上实现了CRI接口的容器引擎都可以作为kubernetes的容器运 行时。 Docker没有实现 (CRI) 接口Kubernetes使用 dockershim 来兼容docker。 自V1.24版本起Dockershim 已从 Kubernetes 项目中移除。 crictl是一个兼容CRI的容器运行时命令他的用法跟 docker 命令一样可以用来检 查和调试底层的运行时容器。
查询运行时的容器
circtl ps
查询镜像
circtl images在一些局域网环境下我们没法通过互联网拉取镜像可以手动的导出、导入镜像 crictl命令没有导出、导入镜像的功能。 需要使用ctr命令导出、导入镜像它是containerd的命令行接口。
不建议使用ctr使用其他操作 只会镜像的导入导出即可
导入镜像(需要指定平台 这里是x64)
k3s默认的镜像都在k8s.io的命名空间下 所以要指定一下ns
ctr -n k8s.io images import ***.tar --platform linux/amd64导出
ctr -n k8s.io images export alpine.tar docker.io/library/alipine:3.15 --platform linux/amd64导入镜像需要在每一台节点上执行才可以
金丝雀发布
金丝雀部署(canary deployment) 也被称为灰度发布。 早期工人下矿井之前会放入一只金丝雀检测井下是否存在有毒气体。 采用金丝雀部署你可以在生产环境的基础设施中小范围的部署新的应用代码。 一旦应用签署发布只有少数用户被路由到它最大限度的降低影响。 如果没有错误发生则将新版本逐渐推广到整个基础设施。
部署过程 部署第一个版本
发布v1版本的应用镜像使用nginx:1.22,数量为 3。
创建Namespace Namespace配置模版创建Deployment Deployment配置模版创建外部访问的Service Service配置模版
示例
apiVersion: v1
kind: Namespace
metadata:name: dev
---
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment-v1namespace: devlabels:app: nginx-deployment-v1
spec:replicas: 3selector:matchLabels: # 跟template.metadata.labels一致app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.22ports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: canary-demonamespace: dev
spec:type: NodePortselector: # 更Deployment中的selector一致app: nginxports:# By default and for convenience, the targetPort is set to the same value as the port field.- port: 80targetPort: 80# Optional field# By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)nodePort: 30008可以通过ns查询
访问
创建Canary Deployment
发布新版本的应用镜像使用docker/getting-started数量为 1。
示例
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment-canarynamespace: devlabels:app: nginx-deployment-canary
spec:replicas: 1selector:matchLabels: # 跟template.metadata.labels一致app: nginxtemplate:metadata:labels:app: nginx #这个pod和service的selector一致 因此新部署的pod会加入到service的负载均衡中track: canaryspec:containers:- name: new-nginximage: docker/getting-startedports:- containerPort: 80查看服务kubectl describe svc canary-demo --namespacedev
待稳定运行一段时间后扩大试用范围将部署的v2版本数量调整为3v1和v2的数量都是3个。
kubectl scale deployment/deploy-v2-canary --replicas3 -ndev
局限性
按照 Kubernetes 默认支持的这种方式进行金丝雀发布有一定的局限性
不能根据用户注册时间、地区等请求中的内容属性进行流量分配同一个用户如果多次调用该 Service有可能第一次请求到了旧版本的 Pod第二次请求到了新版本的 Pod 在 Kubernetes 中不能解决上述局限性的原因是Kubernetes Service 只在 TCP 层面解决负载均衡的问题并不对请求响应的消息内容做任何解析和识别。如果想要更完善地实现金丝雀发布可以考虑Istio灰度发布。 参考文档 https://www.infoq.cn/article/lei4vsfpiw5a6en-aso4 https://kuboard.cn/learning/k8s-intermediate/workload/wl-deployment/canary.html 运行有状态应用(MySQL数据库)
我们以MySQL数据库为例在kubernetes集群中运行一个有状态的应用。
部署数据库几乎覆盖了kubernetes中常见的对象和概念
配置文件–ConfigMap保存密码–Secret数据存储–持久卷(PV)和持久卷声明(PVC)动态创建卷–存储类(StorageClass)部署多个实例–StatefulSet数据库访问–Headless Service主从复制–初始化容器和sidecar数据库调试–port-forward部署Mysql集群–helm
存储
创建Mysql
配置环境变量
使用MySQL镜像创建Pod需要使用环境变量设置MySQL的初始密码。环境变量配置示例
挂载卷
将数据存储在容器中一旦容器被删除数据也会被删除。将数据存储到卷(Volume)中删除容器时卷不会被删除。
hostPath卷
hostPath 卷将主机节点上的文件或目录挂载到 Pod 中。 hostPath配置示例
DirectoryOrCreate目录不存在则自动创建Directory挂载已存在目录。不存在会报错FileOrCreate文件不存在则自动创建。不会自动创建文件的父目录必须确保文件路径已经存在。File挂载已存在的文件。不存在会报错Socket挂载 UNIX 套接字。例如挂载/var/run/docker.sock进程 参考文档 https://kubernetes.io/zh-cn/docs/tasks/inject-data-application/define-environment-variable-container/ https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ ConfigMap与Secret
在Docker中我们一般通过绑定挂载的方式将配置文件挂载到容器里 在Kubernetes集群中容器可能被调度到任意节点配置文件需要能在集群任意节点上 访问、分发和更新
ConfigMap
ConfigMap 用来在键值对数据库(etcd)中保存非加密数据。一般用来保存配置文件。ConfigMap 可以用作环境变量、命令行参数或者存储卷。ConfigMap 将环境配置信息与 容器镜像 解耦便于配置的修改。ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。超出此限制需要考虑挂载存储卷或者访问文件存储服务。
ConfigMap用法
ConfigMap配置示例Pod中使用ConfigMap
apiVersion: v1
kind: Pod
metadata:name: mysql-podlabels:app: mysql
spec:containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ROOT_PASSWORDvalue: 123456volumeMounts:- mountPath: /var/lib/mysqlname: data-volume- mountPath: /etc/mysql/conf.dname: conf-volumereadOnly: truevolumes:- name: conf-volumeconfigMap:name: mysql-config- name: data-volumehostPath:# directory location on hostpath: /home/mysql/data# this field is optionaltype: DirectoryOrCreate
---
apiVersion: v1
kind: ConfigMap
metadata:name: mysql-config
data:mysql.cnf: |[mysqld]character-set-serverutf8mb4collation-serverutf8mb4_general_ciinit-connectSET NAMES utf8mb4[client]default-character-setutf8mb4[mysql]default-character-setutf8mb4configMap可以缩写为cm
# 修改configMap配置文件会被自动更新
kubectl edit cm mysql-configSecret
Secret 用于保存机密数据的对象。一般由于保存密码、令牌或密钥等。 data字段用来存储 base64 编码数据。 stringData存储未编码的字符串。 Secret 意味着你不需要在应用程序代码中包含机密数据减少机密数据(如密码)泄露的风险。 Secret 可以用作环境变量、命令行参数或者存储卷文件。
Secret用法
Secret配置示例将Secret用作环境变量
echo -n 123456 | base64
echo MTIzNDU2 | base64 --decode示例
apiVersion: v1
kind: Secret
metadata:name: mysql-password
type: Opaque
data:PASSWORD: MTIzNDU2Cg
---
apiVersion: v1
kind: Pod
metadata:name: mysql-pod
spec:containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ROOT_PASSWORDvalueFrom:secretKeyRef:name: mysql-passwordkey: PASSWORDoptional: false # 此值为默认值表示secret已经存在了volumeMounts:- mountPath: /var/lib/mysqlname: data-volume- mountPath: /etc/mysql/conf.dname: conf-volumereadOnly: truevolumes:- name: conf-volumeconfigMap:name: mysql-config- name: data-volumehostPath:# directory location on hostpath: /home/mysql/data# this field is optionaltype: DirectoryOrCreate
---
apiVersion: v1
kind: ConfigMap
metadata:name: mysql-config
data:mysql.cnf: |[mysqld]character-set-serverutf8mb4collation-serverutf8mb4_general_ciinit-connectSET NAMES utf8mb4[client]default-character-setutf8mb4[mysql]default-character-setutf8mb4注意当Secret修改后 环境变量的Secret不会自动更新 需要重启pod 参考文档 https://kubernetes.io/zh-cn/docs/concepts/configuration/ https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/ https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/ https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/ 卷(Volume)
将数据存储在容器中一旦容器被删除数据也会被删除。 卷是独立于容器之外的一块存储区域通过挂载(Mount)的方式供Pod中的容器使用。
使用场景
卷可以在多个容器之间共享数据。卷可以将容器数据存储在外部存储或云存储上。卷更容易备份或迁移。
常见的卷类型
临时卷(Ephemeral Volume) 与 Pod 一起创建和删除生命周期与 Pod 相同
emptyDir - 作为缓存或存储日志configMap 、secret、 downwardAPI - 给Pod注入数据
持久卷(Persistent Volume)删除Pod后持久卷不会被删除
本地存储 - hostPath、 local网络存储 - NFS分布式存储 - Ceph(cephfs文件存储、rbd块存储)
投射卷(Projected Volumes)projected 卷可以将多个卷映射到同一个目录上
后端存储
一个集群中可以包含多种存储(如local、NFS、Ceph或云存储)。 每种存储都对应一个存储类StorageClass 存储类用来创建和管理持久卷是集群与存储服务之间的桥梁。 管理员创建持久卷(PV)时通过设置不同的StorageClass来创建不同类型的持久卷。 参考文档 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/ https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/ https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/ 临时卷(EV)
临时卷(Ephemeral Volume)
与 Pod 一起创建和删除生命周期与 Pod 相同emptyDir - 初始内容为空的本地临时目录configMap - 为Pod注入配置文件secret - 为Pod注入加密数据
emptyDir
emptyDir会创建一个初始状态为空的目录存储空间来自本地的 kubelet 根目录或内存(需要将emptyDir.medium设置为Memory)。 通常使用本地临时存储来设置缓存、保存日志等。 例如将redis的存储目录设置为emptyDir
示例
apiVersion: v1
kind: Pod
metadata:name: redis-pod
spec:containers:- name: redisimage: redisvolumeMounts:- name: redis-storagemountPath: /data/redisvolumes:- name: redis-storageemptyDir: {}configMap卷和secret卷 注意 这里的configMap和secret代表的是卷的类型不是configMap和secret对象。 删除Pod并不会删除ConfigMap对象和secret对象。 configMap卷和Secret卷是一种特殊类型的卷kubelet引用configMap和Secret中定义的内容在Pod所在节点上生成一个临时卷将数据注入到Pod中。删除Pod临时卷也会被删除。 临时卷位于Pod所在节点的/var/lib/kubelet/pods目录下。 参考文档 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/ https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/ https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/ 持久卷(PV)与持久卷声明(PVC)
持久卷(Persistent Volume)删除Pod后卷不会被删除
本地存储
hostPath - 节点主机上的目录或文件 (仅供单节点测试使用多节点集群请用 local 卷代替)local - 节点上挂载的本地存储设备(不支持动态创建卷)
网络存储
NFS - 网络文件系统 (NFS)
分布式存储
Ceph(cephfs文件存储、rbd块存储)
持久卷(PV)和持久卷声明(PVC)
持久卷PersistentVolumePV 是集群中的一块存储。可以理解为一块虚拟硬盘。 持久卷可以由管理员事先创建 或者使用存储类Storage Class根据用户请求来动态创建。 持久卷属于集群的公共资源并不属于某个namespace;
持久卷声明PersistentVolumeClaimPVC 表达的是用户对存储的请求。 PVC声明好比申请单它更贴近云服务的使用场景使用资源先申请便于统计和计费。 Pod 将 PVC 声明当做存储卷来使用PVC 可以请求指定容量的存储空间和访问模式 。PVC对象是带有namespace的。
创建持久卷PV
创建持久卷(PV)是服务端的行为通常集群管理员会提前创建一些常用规格的持久卷以备使用。 hostPath仅供单节点测试使用当Pod被重新创建时可能会被调度到与原先不同的节点上导致新的Pod没有数据。多节点集群使用本地存储可以使用local卷 创建local类型的持久卷需要先创建存储类(StorageClass)。
本地存储类示例
# 创建本地存储类
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediatelocal卷不支持动态创建必须手动创建持久卷(PV)。 创建local类型的持久卷必须设置nodeAffinity(节点亲和性)。 调度器使用nodeAffinity信息来将使用local卷的 Pod 调度到持久卷所在的节点上不会出现Pod被调度到别的节点上的情况。 注意 local卷也存在自身的问题当Pod所在节点上的存储出现故障或者整个节点不可用时Pod和卷都会失效仍然会丢失数据因此最安全的做法还是将数据存储到集群之外的存储或云存储上。 ● 创建PV PV示例/local卷示例
apiVersion: v1
kind: PersistentVolume
metadata:name: local-pv-1
spec:capacity:storage: 4GivolumeMode: FilesystemaccessModes:- ReadWriteOncepersistentVolumeReclaimPolicy: DeletestorageClassName: local-storage #通过指定存储类来设置卷的类型local:path: /mnt/disks/ssd1nodeAffinity:required:nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/hostnameoperator: Invalues: #节点亲和度 防止被调度到不同的节点- k8s-worker1创建持久卷声明(PVC)
持久卷声明(PVC)是用户端的行为,用户在创建Pod时无法知道集群中PV的状态(名称、容量、是否可用等)用户也无需关心这些内容只需要在声明中提出申请集群会自动匹配符合需求的持久卷(PV)。
Pod使用持久卷声明(PVC)作为存储卷。
PVC示例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: local-pv-claim
spec:storageClassName: local-storage # 与PV中的storageClassName一致accessModes:- ReadWriteOnceresources:requests:storage: 3Gi使用PVC作为卷
Pod 的配置文件指定了 PersistentVolumeClaim但没有指定 PersistentVolume。 对 Pod 而言PersistentVolumeClaim 就是一个存储卷。 PVC卷示例
apiVersion: v1
kind: Pod
metadata:name: mysql-pod
spec:containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ROOT_PASSWORDvalue: 123456ports:- containerPort: 3306volumeMounts:- mountPath: /var/lib/mysql #容器中的目录name: local-mysql-datavolumes:- name: local-mysql-datapersistentVolumeClaim:claimName: local-pv-claim绑定
创建持久卷声明(PVC)之后集群会查找满足要求的持久卷(PV)将 PVC 绑定到该 PV上。 PVC与PV之间的绑定是一对一的映射关系绑定具有排他性一旦绑定关系建立该PV无法被其他PVC使用。 PVC可能会匹配到比声明容量大的持久卷但是不会匹配比声明容量小的持久卷。 例如即使集群上存在多个 50 G大小的 PV 他们加起来的容量大于100G也无法匹配100 G大小的 PVC。 找不到满足要求的 PV PVC会无限期地处于未绑定状态(Pending) , 直到出现了满足要求的 PV时PVC才会被绑定。
访问模式 ReadWriteOnce 卷可以被一个节点以读写方式挂载并允许同一节点上的多个 Pod 访问。 ReadOnlyMany 卷可以被多个节点以只读方式挂载。 ReadWriteMany 卷可以被多个节点以读写方式挂载。 ReadWriteOncePod 卷可以被单个 Pod 以读写方式挂载。 集群中只有一个 Pod 可以读取或写入该 PVC。 只支持 CSI 卷以及需要 Kubernetes 1.22 以上版本。 卷的状态
Available可用-- 卷是一个空闲资源尚未绑定到任何Bound已绑定-- 该卷已经绑定到某个持久卷声明上Released已释放-- 所绑定的声明已被删除但是资源尚未被集群回收Failed失败-- 卷的自动回收操作失败。
卷模式 卷模式(volumeMode)是一个可选参数。 针对 PV 持久卷Kubernetes 支持两种卷模式volumeModes
Filesystem文件系统 默认的卷模式。Block块 将卷作为原始块设备来使用。 参考文档 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/ https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/ https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ 访问模式
● ReadWriteOnce ○ 卷可以被一个节点以读写方式挂载并允许同一节点上的多个 Pod 访问。 ● ReadOnlyMany ○ 卷可以被多个节点以只读方式挂载。 ● ReadWriteMany ○ 卷可以被多个节点以读写方式挂载。 ● ReadWriteOncePod ○ 卷可以被单个 Pod 以读写方式挂载。 集群中只有一个 Pod 可以读取或写入该 PVC。 ○ 只支持 CSI 卷以及需要 Kubernetes 1.22 以上版本。
卷的状态
Available可用-- 卷是一个空闲资源尚未绑定到任何Bound已绑定-- 该卷已经绑定到某个持久卷声明上Released已释放-- 所绑定的声明已被删除但是资源尚未被集群回收Failed失败-- 卷的自动回收操作失败。
卷模式
卷模式(volumeMode)是一个可选参数。 针对 PV 持久卷Kubernetes 支持两种卷模式volumeModes ● Filesystem文件系统 默认的卷模式。 ● Block块 - 将卷作为原始块设备来使用。 参考文档 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/ https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/ https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ 存储类(StorageClass)
创建持久卷(PV)
● 静态创建
管理员预先手动创建手动创建麻烦、不够灵活local卷不支持动态创建必须手动创建PV资源浪费例如一个PVC可能匹配到比声明容量大的卷对自动化工具不够友好
● 动态创建
根据用户请求按需创建持久卷在用户请求时自动创建动态创建需要使用存储类StorageClass用户需要在持久卷声明(PVC)中指定存储类来自动创建声明中的卷。如果没有指定存储类使用集群中默认的存储类。
存储类(StorageClass)
一个集群可以存在多个存储类StorageClass来创建和管理不同类型的存储。
每个 StorageClass 都有一个制备器Provisioner用来决定使用哪个卷插件创建持久卷。 该字段必须指定。 Local Path Provisioner K3s自带了一个名为local-path的存储类(StorageClass)它支持动态创建基于hostPath或local的持久卷。 创建PVC后会自动创建PV不需要再去手动的创建PV。 删除PVCPV也会被自动删除。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: local-path-pvcnamespace: default
spec:accessModes:- ReadWriteOncestorageClassName: local-pathresources:requests:storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:name: mysql-pod
spec:containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ROOT_PASSWORDvalue: 123456ports:- containerPort: 3306volumeMounts:- mountPath: /var/lib/mysql #容器中的目录name: local-mysql-datavolumes:- name: local-mysql-datapersistentVolumeClaim:claimName: local-path-pvc卷绑定模式
volumeBindingMode用于控制什么时候动态创建卷和绑定卷。 ● Immediate立即创建 创建PVC后立即创建PV并完成绑定。 ● WaitForFirstConsumer 延迟创建 当使用该PVC的 Pod 被创建时才会自动创建PV并完成绑定。
回收策略Reclaim Policy
回收策略告诉集群当用户删除PVC 对象时 从PVC中释放出来的PV将被如何处理。 ● 删除Delete 如果没有指定默认为Delete 当PVC被删除时关联的PV 对象也会被自动删除。 ● 保留Retain 当 PVC 对象被删除时PV 卷仍然存在数据卷状态变为已释放(Released)。 此时卷上仍保留有数据该卷还不能用于其他PVC。需要手动删除PV。 参考文档 https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/ https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode https://rancher.com/docs/k3s/latest/en/storage/ StatefulSet(有状态应用集)
StatefulSet
如果我们需要部署多个MySQL实例就需要用到StatefulSet。 StatefulSet 是用来管理有状态的应用。一般用于管理数据库、缓存等。 与 Deployment 类似 StatefulSet用来管理 Pod 集合的部署和扩缩。 Deployment用来部署无状态应用。StatefulSet用来有状态应用。
创建StatefulSet
StatefulSet配置模版
apiVersion: apps/v1
kind: StatefulSet
metadata:name: mysql
spec:selector:matchLabels:app: mysql # 必须匹配 .spec.template.metadata.labelsserviceName: dbreplicas: 3 # 默认值是 1minReadySeconds: 10 # 默认值是 0template:metadata:labels:app: mysql # 必须匹配 .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ROOT_PASSWORDvalue: 123456ports:- containerPort: 3306volumeMounts:- mountPath: /var/lib/mysql #容器中的目录name: mysql-datavolumeClaimTemplates:- metadata:name: mysql-dataspec:accessModes:- ReadWriteOncestorageClassName: local-pathresources:requests:storage: 2Gi稳定的存储
在 StatefulSet 中使用 VolumeClaimTemplate为每个 Pod 创建持久卷声明(PVC)。 每个 Pod 将会得到基于local-path 存储类动态创建的持久卷(PV)。 Pod 创建(或重新调度时会挂载与其声明相关联的持久卷。 请注意当 Pod 或者 StatefulSet 被删除时持久卷声明和关联的持久卷不会被删除。
Pod 标识
在具有 N 个副本的 StatefulSet中每个 Pod 会被分配一个从 0 到 N-1 的整数序号该序号在此 StatefulSet 上是唯一的。 StatefulSet 中的每个 Pod 主机名的格式为StatefulSet名称-序号。 上例将会创建三个名称分别为 mysql-0、mysql-1、mysql-2 的 Pod。
部署和扩缩保证
对于包含 N 个 副本的 StatefulSet当部署 Pod 时它们是依次创建的顺序为 0…N-1。当删除 Pod 时它们是逆序终止的顺序为 N-1…0。在将扩缩操作应用到 Pod 之前它前面的所有 Pod 必须是 Running 和 Ready 状态。在一个 Pod 终止之前所有的继任者必须完全关闭。
在上面的mysql示例被创建后会按照 mysql-0、mysql-1、mysql-2 的顺序部署三个 Pod。 在 mysql-0 进入 Running 和 Ready 状态前不会部署 mysql-1。 在 mysql-1 进入 Running 和 Ready 状态前不会部署 mysql-2。 如果 mysql-1 已经处于 Running 和 Ready 状态而 mysql-2 尚未部署在此期间发生了 mysql-0 运行失败那么 mysql-2 将不会被部署要等到 mysql-0 部署完成并进入 Running 和 Ready 状态后才会部署 mysql-2。 如果用户想将示例中的 StatefulSet 扩缩为 replicas1首先被终止的是 mysql-2。 在 mysql-2 没有被完全停止和删除前mysql-1 不会被终止。 当 mysql-2 已被终止和删除、mysql-1 尚未被终止如果在此期间发生 mysql-0 运行失败 那么就不会终止 mysql-1必须等到 mysql-0 进入 Running 和 Ready 状态后才会终止 web-1。 参考文档 https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/ https://kubernetes.io/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/ Headless Service(无头服务)
之前我们创建了三个各自独立的数据库实例mysql-0mysql-1mysql-2。
要想让别的容器访问数据库我们需要将它发布为Service但是Service带负载均衡功能每次请求都会转发给不同的数据库这样子使用过程中会有很大的问题。
无头服务Headless Services
无头服务Headless Service可以为 StatefulSet 成员提供稳定的 DNS 地址。
在不需要负载均衡的情况下可以通过指定 Cluster IP的值为 “None” 来创建无头服务。 注意:StatefulSet中的ServiceName必须要跟Service中的metadata.name一致 # 为 StatefulSet 成员提供稳定的 DNS 表项的无头服务Headless Service
apiVersion: v1
kind: Service
metadata:#重要这里的名字要跟后面StatefulSet里ServiceName一致name: dblabels:app: database
spec:ports:- name: mysqlport: 3306# 设置Headless ServiceclusterIP: Noneselector:app: mysql
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: mysql
spec:selector:matchLabels:app: mysql # 必须匹配 .spec.template.metadata.labelsserviceName: db #重要这里的名字要跟Service中metadata.name匹配replicas: 3 # 默认值是 1minReadySeconds: 10 # 默认值是 0template:metadata:labels:app: mysql # 必须匹配 .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ROOT_PASSWORDvalue: 123456ports:- containerPort: 3306volumeMounts:- mountPath: /var/lib/mysqlname: mysql-datavolumeClaimTemplates:- metadata:name: mysql-dataspec:accessModes:- ReadWriteOncestorageClassName: local-pathresources:requests:storage: 2Gi稳定的网络 ID
StatefulSet 中的每个 Pod 都会被分配一个StatefulSet名称-序号格式的主机名。
集群内置的DNS会为Service分配一个内部域名db.default.svc.cluster.local,它的格式为 服务名称.命名空间.svc.cluster.local。
Service下的每个Pod会被分配一个子域名格式为pod名称.所属服务的域名例如mysql-0的域名为mysql-0.db.default.svc.cluster.local。添加链接描述
创建Pod时DNS域名生效可能会有一些延迟(几秒或几十秒)。 Pod之间可以通过DNS域名访问同一个命名空间下可以省略命名空间及其之后的内容。
kubectl run dns-test -it --imagebusybox:1.28 --rm
# 访问mysql-0数据库
nslookup mysql-0.db参考文档 https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/ https://kubernetes.io/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/ https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services https://kubernetes.io/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/ https://kubernetes.io/zh-cn/docs/concepts/services-networking/dns-pod-service/ Mysql主从复制 注意 1.本例子配置比较复杂仅用于讲解原理无需掌握配置细节。 2.后面我们会讲使用helm自动化部署用起来非常简单。 3.本例子不能用于生产mysql的密码允许设置为空。 下面是部署一个读写分离Mysql数据库的示意图。 通过部署无头服务(Headless Service)将写操作指向固定的数据库。 部署一个Service用来做读操作的负载均衡。 数据库之间通过同步程序保持数据一致。
Mysql主从复制
运行一个有状态的应用程序
注意 1.官方的安装文档有错误mysql镜像需要使用mysql:5.7-debian。否则会出现如下错误 详见https://github.com/kubernetes/website/pull/35857。 2.谷歌的镜像·gcr.io/google-samples/xtrabackup:1.0·访问不到使用·ist0ne/xtrabackup:1.0·代替
apiVersion: v1
kind: ConfigMap
metadata:name: mysqllabels:app: mysqlapp.kubernetes.io/name: mysql
data:primary.cnf: |# 仅在主服务器上应用此配置[mysqld]log-bin replica.cnf: |# 仅在副本服务器上应用此配置[mysqld]super-read-only
---
# 为 StatefulSet 成员提供稳定的 DNS 表项的无头服务Headless Service
apiVersion: v1
kind: Service
metadata:name: mysqllabels:app: mysqlapp.kubernetes.io/name: mysql
spec:ports:- name: mysqlport: 3306clusterIP: Noneselector:app: mysql
---
# 用于连接到任一 MySQL 实例执行读操作的客户端服务
# 对于写操作你必须连接到主服务器mysql-0.mysql
apiVersion: v1
kind: Service
metadata:name: mysql-readlabels:app: mysqlapp.kubernetes.io/name: mysqlreadonly: true
spec:ports:- name: mysqlport: 3306selector:app: mysqlapiVersion: apps/v1
kind: StatefulSet
metadata:name: mysql
spec:selector:matchLabels:app: mysqlapp.kubernetes.io/name: mysqlserviceName: mysqlreplicas: 3template:metadata:labels:app: mysqlapp.kubernetes.io/name: mysqlspec:initContainers:- name: init-mysqlimage: mysql:5.7-debiancommand:- bash- -c- |set -ex# 基于 Pod 序号生成 MySQL 服务器的 ID。[[ hostname ~ -([0-9])$ ]] || exit 1ordinal${BASH_REMATCH[1]}echo [mysqld] /mnt/conf.d/server-id.cnf# 添加偏移量以避免使用 server-id0 这一保留值。echo server-id$((100 $ordinal)) /mnt/conf.d/server-id.cnf# 将合适的 conf.d 文件从 config-map 复制到 emptyDir。if [[ $ordinal -eq 0 ]]; thencp /mnt/config-map/primary.cnf /mnt/conf.d/elsecp /mnt/config-map/replica.cnf /mnt/conf.d/fi volumeMounts:- name: confmountPath: /mnt/conf.d- name: config-mapmountPath: /mnt/config-map- name: clone-mysqlimage: ist0ne/xtrabackup:1.0command:- bash- -c- |set -ex# 如果已有数据则跳过克隆。[[ -d /var/lib/mysql/mysql ]] exit 0# 跳过主实例序号索引 0的克隆。[[ hostname ~ -([0-9])$ ]] || exit 1ordinal${BASH_REMATCH[1]}[[ $ordinal -eq 0 ]] exit 0# 从原来的对等节点克隆数据。ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql# 准备备份。xtrabackup --prepare --target-dir/var/lib/mysql volumeMounts:- name: datamountPath: /var/lib/mysqlsubPath: mysql- name: confmountPath: /etc/mysql/conf.dcontainers:- name: mysqlimage: mysql:5.7-debianenv:- name: MYSQL_ALLOW_EMPTY_PASSWORDvalue: 1ports:- name: mysqlcontainerPort: 3306volumeMounts:- name: datamountPath: /var/lib/mysqlsubPath: mysql- name: confmountPath: /etc/mysql/conf.dresources:requests:cpu: 500mmemory: 1GilivenessProbe:exec:command: [mysqladmin, ping]initialDelaySeconds: 30periodSeconds: 10timeoutSeconds: 5readinessProbe:exec:# 检查我们是否可以通过 TCP 执行查询skip-networking 是关闭的。command: [mysql, -h, 127.0.0.1, -e, SELECT 1]initialDelaySeconds: 5periodSeconds: 2timeoutSeconds: 1- name: xtrabackupimage: ist0ne/xtrabackup:1.0ports:- name: xtrabackupcontainerPort: 3307command:- bash- -c- |set -excd /var/lib/mysql# 确定克隆数据的 binlog 位置如果有的话。if [[ -f xtrabackup_slave_info x$(xtrabackup_slave_info) ! x ]]; then# XtraBackup 已经生成了部分的 “CHANGE MASTER TO” 查询# 因为我们从一个现有副本进行克隆。(需要删除末尾的分号!)cat xtrabackup_slave_info | sed -E s/;$//g change_master_to.sql.in# 在这里要忽略 xtrabackup_binlog_info 它是没用的。rm -f xtrabackup_slave_info xtrabackup_binlog_infoelif [[ -f xtrabackup_binlog_info ]]; then# 我们直接从主实例进行克隆。解析 binlog 位置。[[ cat xtrabackup_binlog_info ~ ^(.*?)[[:space:]](.*?)$ ]] || exit 1rm -f xtrabackup_binlog_info xtrabackup_slave_infoecho CHANGE MASTER TO MASTER_LOG_FILE${BASH_REMATCH[1]},\MASTER_LOG_POS${BASH_REMATCH[2]} change_master_to.sql.infi# 检查我们是否需要通过启动复制来完成克隆。if [[ -f change_master_to.sql.in ]]; thenecho Waiting for mysqld to be ready (accepting connections)until mysql -h 127.0.0.1 -e SELECT 1; do sleep 1; doneecho Initializing replication from clone positionmysql -h 127.0.0.1 \-e $(change_master_to.sql.in), \MASTER_HOSTmysql-0.mysql, \MASTER_USERroot, \MASTER_PASSWORD, \MASTER_CONNECT_RETRY10; \START SLAVE; || exit 1# 如果容器重新启动最多尝试一次。mv change_master_to.sql.in change_master_to.sql.origfi# 当对等点请求时启动服务器发送备份。exec ncat --listen --keep-open --send-only --max-conns1 3307 -c \xtrabackup --backup --slave-info --streamxbstream --host127.0.0.1 --userroot volumeMounts:- name: datamountPath: /var/lib/mysqlsubPath: mysql- name: confmountPath: /etc/mysql/conf.dresources:requests:cpu: 100mmemory: 100Mivolumes:- name: confemptyDir: {}- name: config-mapconfigMap:name: mysqlvolumeClaimTemplates:- metadata:name: dataspec:accessModes: [ReadWriteOnce]resources:requests:storage: 2Gi初始化容器(Init Containers)
初始化容器(Init Containers)是一种特殊容器它在 Pod 内的应用容器启动之前运行。 初始化容器未执行完毕或以错误状态退出Pod内的应用容器不会启动。 初始化容器需要在initContainers中定义与containers同级。 基于上面的特性初始化容器通常用于
生成配置文件执行初始化命令或脚本执行健康检查检查依赖的服务是否处于Ready或健康Health的状态 在本例子中有两个初始化容器。
init-mysql为MySQL实例分配server-id,并将mysql-0的配置文件设置为primary.cnf,其他副本设置为replica.cnfclone-mysql从前一个Pod中获取备份的数据文件放到自己的数据目录下
边车Sidecar
Pod中运行了2个容器MySQL 容器和一个充当辅助工具的 xtrabackup 容器我们称之为边车(sidecar)。
Xtrabackup是一个开源的MySQL备份工具支持在线热备份备份时不影响数据读写是目前各个云厂商普遍使用的MySQL备份工具。 sidecar容器负责将备份的数据文件发送给下一个Pod并在副本服务器初次启动时使用数据文件完成数据的导入。
MySQL使用bin-log同步数据但是当数据库运行一段时间后产生了一些数据这时候如果我们进行扩容创建了一个新的副本有可能追溯不到bin-log的源头(可能被手动清理或者过期自动删除)因此需要将现有的数据导入到副本之后再开启数据同步sidecar只负责数据库初次启动时完成历史数据导入后续的数据MySQL会自动同步。
客户端连接
写操作 写操作连接mysql-0.mysql
kubectl run mysql-client --imagemysql:5.7 -it --rm \-- mysql -h mysql-0.mysqlCREATE DATABASE test;
CREATE TABLE test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES (hello);读操作
读操作连接到mysql-read它是一个service会自动将请求负载均衡到后端的三个mysql实例上。
kubectl run mysql-client --imagemysql:5.7 -it --rm \-- mysql -h mysql-readSELECT * FROM test.messages参考文档 https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/ https://kubernetes.io/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/ 深入理解StatefulSet:有状态应用实践 Port-forward端口转发
通常集群中的数据库不直接对外访问。 但是有时候我们需要图形化工具连接到数据库进行操作或者调试。 我们可以使用端口转发来访问集群中的应用。 kubectl port-forward可以将本地端口的连接转发给容器。 此命令在前台运行命令终止后转发会话将结束。 这种类型的连接对数据库调试很有用。 #主机端口在前容器端口在后
#如果主机有多个IP需要指定IP如不指定IP默认为127.0.0.1
kubectl port-forward pods/mysql-0 --address192.168.56.109 33060:3306网络访问
● 容器中应用访问数据库 ○ 读操作mysql-read:3306 ○ 写操作mysql-0.mysql:3306 ● 集群中的Node访问 ○ ClusterIPport ● 集群外的主机访问 ○ 主机IPnodePort 参考资料 https://kubernetes.io/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/ https://kubernetes.io/zh-cn/docs/concepts/services-networking/dns-pod-service/ https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/
Helm安装MySQL机群
Helm简介与安装
Helm 是一个 Kubernetes 应用的包管理工具类似于 Ubuntu 的 APT 和 CentOS 中的 YUM。 Helm使用chart 来封装kubernetes应用的 YAML 文件我们只需要设置自己的参数就可以实现自动化的快速部署应用。 安装Helm 下载安装包 https://github.com/helm/helm/releases https://get.helm.sh/helm-v3.10.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm在K3s中使用需要配置环境变量
export KUBECONFIG/etc/rancher/k3s/k3s.yaml三大概念
● Chart 代表着 Helm 包。 ○ 它包含运行应用程序需要的所有资源定义和依赖相当于模版。 ○ 类似于maven中的pom.xml、Apt中的dpkb或 Yum中的RPM。 ● Repository仓库 用来存放和共享 charts。 ○ 不用的应用放在不同的仓库中。 ● Release 是运行 chart 的实例。 一个 chart 通常可以在同一个集群中安装多次。 每一次安装都会创建一个新的 releaserelease name不能重复。
Helm仓库 Helm有一个跟docker Hub类似的应用中心https://artifacthub.io/我们可以在里面找到我们需要部署的应用。
安装单节点Mysql
#添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
#查看chart
helm show chart bitnami/mysql
#查看默认值
helm show values bitnami/mysql #安装mysql
helm install my-mysql \
--set-string auth.rootPassword123456 \
--set primary.persistence.size2Gi \
bitnami/mysql#查看设置
helm get values my-mysql
#删除mysql
helm delete my-releaseHelm部署MySQL集群
安装过程中有两种方式传递配置数据 ● -f (或--values):使用 YAML 文件覆盖默认配置。可以指定多次优先使用最右边的文件。 ● --set:通过命令行的方式对指定项进行覆盖。 如果同时使用两种方式则 --set中的值会被合并到 -f中但是 --set中的值优先级更高。
使用配置文件设置MySQL的参数。
auth:rootPassword: 123456primary:persistence:size: 2Gienabled: truesecondary:replicaCount: 2persistence:size: 2Gienabled: truearchitecture: replicationhelm install my-db -f values.yaml bitnami/mysql参考文档 https://helm.sh/zh/docs/intro/install/ https://helm.sh/zh/docs/intro/using_helm/
部署若依(RuoYi-Vue)
