Jenkins pod的存储和网络

type

status

date

slug

summary

1. 写在前面

在Kubernetes中使用Jenkins的优点：

Master服务高可用：当Jenkins Master出现故障时，Kubernetes 会自动创建一个新的Jenkins Master容器，并且将Volume分配给新创建的容器，保证数据不丢失，从而达到集群服务高可用。注：至于Volume是否持久化是另一个问题。

Slave动态伸缩：合理使用资源，每次运行Job时，会自动创建一个Jenkins Slave，Job完成后，Slave自动注销并删除容器，资源自动释放，而且Kubernetes会根据每个资源使用情况，动态分配Slave到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。注：slave pod在集群任意节点执行任务，有隐藏的点：npm等下载依赖包的任务需要网络，故集群每台节点都需要网络权限；npm等任务遗留的依赖包是否需要保留，保留依赖包涉及持久化。

扩展性好：当Kubernetes集群的资源严重不足而导致Job排队等待时，可以很容易的添加一个Kubernetes Node到集群中，从而实现扩展。

2. 网络

slave pod在任意节点run本来是为了方便扩展，但是带来的网络问题需要考虑，npm构建等需要网络，当然也可以直接使用内部仓库。

3. 持久化

持久化主要是三个地方：Jenkins master的$home，Jenkins slave的$home，maven/npm 的缓存。

不建议在生产环境使用NFS，NFS有各种问题，特别是不支持容量扩展。

NFS的一个坑”StorageClass ‘nfs’: claim Selector is not supported”

💡

一般情况，PVC通过spec.selector可以指定PV，但NFS不支持。

我测试的场景：Jenkins通过PVC给StorageClass ‘nfs’申请了PV，修改PV回收策略为Retain、打tag便于绑定。接着删除deployment，删除PVC，然后新增PVC的spec.selector指定tag，结果提示”StorageClass ‘nfs’: claim Selector is not supported”。所以，使用NFS的情况下，即使你的PV回收策略避免了delete，下次也不能直接重新利用这个PV。即使SC配置了”allowVolumeExpansion: true”，仍然报错”didn't find a plugin capable of expanding the volume; waiting for an external controller to process this PVC.”，参见

Although the feature is enabled by default, a cluster admin must opt-in to allow users to resize their volumes. Kubernetes v1.11 ships with volume expansion support for the following in-tree volume plugins: AWS-EBS, GCE-PD, Azure Disk, Azure File, Glusterfs, Cinder, Portworx, and Ceph RBD

Jenkins master可以是多种形式的部署，无论怎样，如果需要pod形式的slave，那就安装k8s插件。如果master是pod形式，不考虑云厂商的话，那pv持久化可以考虑hostpath、localPV，即本地存储。Jenkins master的replicaset=1，不用担心数据错乱。master存储的是Jenkins的重要数据，通常量不会很大，故hostpath更适合。因为hostpath直接使用本地目录，不能申领空间大小。而localPV通常需要额外挂载一块盘，会占据整个盘的空间，即使你申请的空间远小于整个盘。 more

💡

一旦使用本地单点存储，就涉及数据备份的问题。

localPV出现的原因

1．如果使用hostPath Volume这种方法 , 还得在deployment中选择节点来调度。当然localPV也需要节点亲和配置，相当于把节点选择对pod隐藏了。

2．需要事先创建好目录 , 而且还得注意权限的配置, 比如root用户创建的目录 , 普通用户就用不了了

3．不能指定大小 , 可能会面临磁盘随时被写满的危险 , 而且没有I/O隔离机制

4．statefulset不能使用hostPath Volume , 写好的Helm不能兼容hostPath Volume

localPV利用lvm扩展

在使用Local PV进行测试的时候，是无法对Pod使用的Local PV容量进行限制的，Pod会一直使用挂载的Local PV的容量。因此，Local PV不支持动态的PV空间申请管理。也就是说，需要手动对Local PV进行容量规划，需要对能够使用的本地资源做一个全局规划，然后划分为各种尺寸的卷后挂载到自动发现目录下。

如果容器分配的一个存储空间不够用了怎么办？

建议使用Linux下的LVM（逻辑分区管理）来管理每个node节点上的本地磁盘存储空间。

<1>创建一个大的VG分组，把一个node节点上可以使用的存储空间都放进去；

<2>按未来一段时间内的容器存储空间使用预期，提前批量创建出一部分逻辑卷LVs，都挂载到自动发现目录下去；

<3>不要把VG中的存储资源全部用尽，预留少部分用于未来给个别容器扩容存储空间的资源；

<4>使用lvextend为特定容器使用的存储卷进行扩容；

如果使用云厂商的块存储，扩容会更方便。如果整块盘不分区，直接格式化后挂载使用，扩容时只需要两部：1.控制台扩容云盘（付费），2.文件格式扩容（已创建快照）。不停止pod应用，直接在线扩容文件格式可能会出现数据问题（小概率），故快照尤其重要。

Jenkins slave pod 的持久化看需求，因为理论上构建出来的jar等制品会全流程打包，最终推送到仓库。而npm等依赖包非常占用空间，为了加快构建速度而花费更多的空间，这需要取舍。建议配置国内仓库以加速依赖包拉取的速度，slave pod执行完任务立即销毁。因为传统部署的Jenkins job通常会配置：构建前删除workspace、构建后删除workspace。

如果Jenkins slave pod 确实需要持久化，可以考虑半残的NFS，因为不需要云厂商支持，而且数据重要性一般。

4. 其他

没有必要极致追求Jenkins的高可用，至少目前未看到完美的方案。故一般情况下master单节点部署即可，重点文件启用备份。Jenkins不是业务系统，包括监控平台等，只是为了辅助业务。如果为了大而全来做，本末倒置了，倒不如先有个backup或者较易拓展的方案，后续根据实际调整。