kubernetes使用本地磁盘进行动态管理pv

前言 使用本地磁盘作为pv kubernetes从1.10版本开始支持local volume(本地卷),workload(不仅是statefulsets类型)可以充分利用本地磁盘的优势,从而获取比remote volume(如nas, nfs, cephfs、RBD)更好的性能。 在local volume出现之前,statefulsets也可以利用本地磁盘,方法是配置hostPath,并通过nodeSelector或者nodeAffinity绑定到具体node上。但hostPath的问题是,管理员需要手动管理集群各个node的目录,不太方便。 以上无论是hostPath还是local volume都不支持动态扩容,并且程序移植改动比较大。 由于项目的需要,需要支持动态创建和扩容pv/pvc 本文参考了以下两个开源项目: https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner https://github.com/rancher/local-path-provisioner 经过测试: kubernetes-sigs版不支持动态扩容/动态供给dynamically provisioning,而且需要提前手动在node节点上创建并且mount对应的挂载点。 Rancher版本的local-path-provisioner支持动态创建挂载点,动态创建pv 下面两种方法都介绍一下安全和使用方式,最后推荐使用第三章介绍的local-path-provisioner来进行动态创建pv 第一章 使用sig-storage-local-static-provisioner 1.1 拉取官方源码进行安装

1.2创建storageclass

1.3挂载磁盘 其Provisioner本身其并不提供local volume,但它在各个节点上的provisioner会去动态的“发现”挂载点(discovery directory),当某node的provisioner在/mnt/fast-disks目录下发现有挂载点时,会创建PV,该PV的local.path就是挂载点,并设置nodeAffinity为该node。 可以用以下脚本通过mount bind方式创建和挂载磁盘

下面是在各个node节点用以上脚本创建挂载点: 执行该脚本后,等待一会,执行查询pv命令,就可以发现自动创建了 1.4测试pod是否可以运行

可以看到, 三个pod都正常运行起来了: 第二章 使用local-path-provisioner 2.1下载yaml文件

2.2 修改 其中有几处需要做修改 2.2.1 删除调试模式 删除–debug 2.2.2修改reclaimPolicy Read more…

在 Nginx 1.25+ 中开启 HTTP/3

对于Nginx来说,在编译时需要配置对于的SSL库,不管是HTTP3.0还是HTTP2.0,始终都要基于HTTPS,而加密算法这块主要有OpenSSL来提供,而BoringSSL是谷歌创建的OpenSSL分支,用于支持TLS1.3的UDP协议0-RTT数据传输的加密算法(可以理解成TLS 1.3是标准协议,BoringSSL是实现工具),BoringSSL的一些特性会在合适的时机同步给OpenSSl。Nginx从1.25.0开始支持QUIC和HTTP/3协议。此外,从1.25.0开始,Linux二进制包中提供了QUIC和HTTP/3支持 QUIC和HTTP/3支持是实验性的 安装BoringSSL证书 官方推荐了3种SSL库,参考文档https://nginx.org/en/docs/quic.html 我这里使用BoringSSL 使用 BoringSSL 编译 NGINX,需要满足以下要求: gcc 版本大于6 编译BoringSSL 需要go环境支持 cmake 3版本以上   升级cmake: workon py_env #yum install ninja-build pip install -U cmake   升级gcc至8: 添加源:

yum install devtoolset-8 激活:source /opt/rh/devtoolset-8/enable 此时通过gcc –version命令可以看到,gcc版本已经变成8.x.x,值得注意的是这仅仅在当前bash生效,如果需要永久生效,可以请自行添加环境变量。   golang安装: wget https://golang.google.cn/dl/go1.21.4.linux-amd64.tar.gz tar -C /usr/local/ -zxvf go1.21.4.linux-amd64.tar.gz   拉取BoringSSL源码 git Read more…

PaaS私有化产品部署离线安装源适配问题解决指南

前言 最新在适配我司产品在信创操作系统各个版本上的安装,在踩了很多坑后, 总结出了一套有效的适配流程,在此记录一下。 由于信创国产化操作系统都是基于openEuler系统或Centos系统来的,包括系统软件包名字,release号等都修改了,在信创服务器上安装产品其实最大的工作量是需要适配跟系统相关的软件,和编译arm64版的二进制文件,尤其前一个比较难弄,因为有很多信创系统和发行版本,我们的目标是, 利用一台x86_64或者arm64架构的机器来构建所有的软件源,基本思路就是: 由于官方没有信创docker镜像,需要自己做,首先需要制作信创os docker镜像的流程是: 启动一个容器做构建环境(如:centos) –> 配置官方源 –> 通过yum –installroot=… 来创建基本的系统目录 –> 通过tar打包系统 –> docker import做成镜像 docker run起来信创系统docker镜像用作构建环境—> 配置官方源 —通过repotrack下载–> 打包成nexus 适配细节 首先是制作os docker镜像,下面是制作脚本:

脚本逻辑解析: 由于一些信创操作系统中安装软件时需要认证机制,所以需要提前将认证放入对应目录(可以从安装好的os虚机中获取),此认证文件经过测试可以用到其它发行版本上,所以以后版本更新不用再更新此文件 脚本参数解析:

  –image_arch: 构建的架构,默认两种架构同时构建 –iso_path: 官方发行版.iso后缀的镜像文件地址,如果提供此参数,则os镜像从.iso文件中的repo源进行制作,构建出来的镜像软件版本与.iso文件中的版本保持一致,如果不提供此参数, 则脚本默认会从官方在线的repo软件源中去下载发行版对应的软件版本,可能会存在某些软件跟.iso文件中不一致(经过测试,仅中科方德安装openssl时出现了依赖不一致)   定义软件清单 下载离线源时,通过定义一下packages.yaml文件,来定义全部所需的软件包: packages.yaml:

定义各系统构建使用的Dockerfile 下面是制作麒麟离线源的Dockerfile:

中科方德在适配过程中出现了很多问题,总结如下: 官方没有docker-ce-20.10.17版本,需要配置docker el8源 官方没有sshpass等包,需要配置centos7的源 Read more…