Jenkins 可以很好地与 Kubernetes 集成,不管是控制器(controller)还是构建节点(agent),都能以 Pod 的形式运行在 Kubernetes 上。 熟悉 Jenkins 的用户,都知道 Jenkins 支持多种类型的构建节点,例如:固定配置、动态配置。而节点与控制器连接的方式, 又包括:JNLP、SSH 等。对于已经在全面拥抱容器技术的用户,大多数是通过连接 Kubernetes 集群并动态启动、销毁 Pod 的方式来使用构建节点。 而随着构建节点的种类、数量增多后,如何更有效地维护这些基于 Kubernetes 的节点,则逐渐成为一个问题。而在这篇文章中, 我将会介绍一种基于配置即代码的方案来管理、维护构建节点。
本文主要讲 Apache Spark 在 on Kubernetes 的 PodTemplate 的问题,以及也会讲到 Spark Operator 里关于 PodTemplate 的问题,当然也会讲到 Apache Spark 2.2 on Kubernetes 那个 Fork 的版本,感兴趣的同学可以往下看看。
最近我们构建和部署服务的方式与原来相比简直就是突飞猛进,像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久,终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性,都会去拆解成各种相互依赖小、解耦性强的微服务,这些服务有各自的依赖和进度。如果你想去构建你所负责的服务,那么从一开始,就应该使用 CI/CD 的方式;当然,如果你走上了这条路, Jenkins 就是你的良师益友。
虽然云原生时代有了Jenkins X、Drone、Tekton 这样的后起之秀,但 Jenkins 这样一个老牌的 CI/CD 工具仍是各大公司主流的使用方案。
由于以上种种痛点,我们渴望一种更高效更可靠的方式来完成这个 CI/CD 流程,而 Docker 虚拟化容器技术能很好的解决这个痛点,下图是基于 Kubernetes 搭建 Jenkins 集群的简单示意图。
虽然云原生时代有了 JenkinsX[1]、Drone[2]、Tekton[3] 这样的后起之秀,但 Jenkins 这样一个老牌的 CI/CD 工具仍是各大公司主流的使用方案。比如我司的私有云产品打包发布就是用这老家伙完成的。然而传统的 Jenkins Slave 一主多从方式会存在一些痛点,比如:
为了方便集成 Maven、Kubernetes、配置文件等等,这里需要安装几个别的插件,这里插件可以在 系统管理—>插件管理—>可选插件 里面安装下面列出的插件。
首先明确软件版本,我这里使用的是 Jenkinsver.2.121.3 ,这个版本比较老,其上安装 Kubernetes 插件所使用 kubectl 版本也比较老,无法使用 Kustomize 的 yaml 文件需要的 apiVersion:apps/v1 ,直接使用生成 deploy.yaml 文件会报错,所以这里选择了自己构建一个包含 kubectl 和 kustomize 的镜像,在镜像中使用 Kustomize 生成所需 yaml 文件并在 Kubernetes 上部署。
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod 中同时运行多个容器时,这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了这些问题。
容器中的磁盘文件随着容器的生而生,随着容器的死而灭,这给运行在容器中的重要应用来说存在一些问题:
DaemonSet 确保全部(或者某些)节点上运行一个 Pod 的副本。当有节点加入集群时, 也会为他们新增一个 Pod 。当有节点从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
要实现在 Jenkins 中的构建工作,可以有多种方式,我们这里采用比较常用的 Pipeline 这种方式。Pipeline,简单来说,就是一套运行在 Jenkins 上的工作流框架,将原来独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂流程编排和可视化的工作。
ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者 JSON 二进制大对象。
Docker 中也有一个 volume 的概念,尽管它稍微宽松一些,管理也很少。在 Docker 中,卷就像是磁盘或是另一个容器中的一个目录。它的生命周期不受管理,直到最近才有了 local-disk-backed 卷。Docker 现在提供了卷驱动程序,但是功能还非常有限(例如Docker1.7只允许每个容器使用一个卷驱动,并且无法给卷传递参数)。
注意,这里我并没有在pod template中配置container,因为官方说明中每个PodTemplate都有一个默认的container(叫jnlp)。建两个PodTemplate方便比较剖析。
由于容器本身是非持久化的,因此需要解决在容器中运行应用程序遇到的一些问题。首先,当容器崩溃时,kubelet将重新启动容器,但是写入容器的文件将会丢失,容器将会以镜像的初始状态重新开始;第二,在通过一个Pod中一起运行的容器,通常需要共享容器之间一些文件。Kubernetes通过存储卷解决上述的两个问题。
Kubernetes 是一个可扩展的开源平台(Google 在 2014 年开源),用于管理容器化的工作负载和服务,可促进声明式配置和自动化。名称 Kubernetes 源于希腊语,意为“舵手”或“飞行员”,通常简称为k8s。
https://gitee.com/future-cicd/jenkinsfile
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时, kubelet会重启它,但是容器中的文件将丢失--容器以干净的状态(镜像最初的状态)重新启动。其次,在 Pod中同时运行多个容器时,这些容器之间通常需要共享文件。Kubernetes中的volume抽象就很好的解决了这些问题
Pod是Kubernetes项目里定义的最小可调度单元,是Kubernetes对应用程序的抽象。在这篇文章里我将会介绍Kubernetes里Pod的基本概念,使用方式,生命周期以及如何使用Pod部署应用。读这篇文章的朋友我会默认你已经了解Kubernete是用来解决什么问题的,以及电脑上已经安装了Minikube这个能试验Kubernetes功能的工具。如果尚未做好这些准备工作,推荐先去看下面的两篇文章做好准备工作后再来学习这里的内容。
我们利用 Kubernetes 来动态运行 Jenkins 的 Slave 节点,可以和好的来解决传统的 Jenkins Slave 浪费大量资源的缺点。之前的示例中我们是将项目放置在 Github 仓库上的,将 Docker 镜像推送到了 Docker Hub,这节课我们来结合我们前面学习的知识点来综合运用下,使用 Jenkins、Gitlab、Harbor、Helm、Kubernetes 来实现一个完整的持续集成和持续部署的流水线作业。
以 Flink 和 Spark 为代表的分布式流批计算框架的下层资源管理平台逐渐从 Hadoop 生态的 YARN 转向 Kubernetes 生态的 k8s 原生 scheduler 以及周边资源调度器,比如 Volcano 和 Yunikorn 等。这篇文章简单比较一下两种计算框架在 Native Kubernetes 的支持和实现上的异同,以及对于应用到生产环境我们还需要做些什么。
3. Jenkins pipeline基础知识:见 链接jenkinspipeline
前言: CVM CDN https://cloud.tencent.com/act?from=10680 https://cloud.tencent.com/act/season?from=14065
在之前的博文中,我们已经知道了很多 K8S 中的组件了,包括资源控制器等。在资源控制器中,我们说到了 StatefulSet 这个控制器组件,其专门为了有状态服务而生的,而对应的存储要存放到哪里呢?
Horovod 是一款基于 AllReduce 的分布式训练框架。凭借其对 TensorFlow、PyTorch 等主流深度学习框架的支持,以及通信优化等特点,Horovod 被广泛应用于数据并行的训练中。
前面的章节中我们介绍了在 Kubernetes 中的持久化存储的使用,了解了 PV、PVC 以及 StorageClass 的使用方法,从本地存储到 Ceph 共享存储都有学习,到这里我们其实已经可以完成应用各种场景的数据持久化了,但是难免在实际的使用过程中会遇到各种各样的问题,要解决这些问题最好的方式就是来了解下 Kubernetes 中存储的实现原理。
持久卷(PersistentVolume,PV) 是集群中的一块存储,可以由管理员事先制备, 或者使用存储类(Storage Class)来动态制备。 持久卷是集群资源,就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样, 也是使用卷插件来实现的,只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。
在 Kubernetes 项目中,cmd/kubeadm/app/phases 目录中的文件是用于实现 kubeadm 工具的不同阶段的逻辑。kubeadm 是一个命令行工具,用于在 Kubernetes 集群中初始化和管理主节点(control plane)。
控制器是指可以对Pod进行管理的一些工作负载,他们可以按照用户的期待来完成一系列Pod的操作。
PV是对底层网络共享存储的抽象,将共享存储定义为一种“资源”,比如Node也是容器应用可以消费的资源。PV由管理员创建和配置,与共享存储的具体实现直接相关。
PV和PVC是kubernetes存储管理中的重要概念,在日常生产场景中使用非常广泛。本文主要介绍PV和PVC在kubernetes中的基本概念、使用场景以及实现原理。更多PV和PVC的使用细节问题请参考kubernetes官方文档。
0. 前言 最近在学习张磊老师的 深入剖析Kubernetes 系列课程,最近学到了 Kubernetes 容器持久化存储部分 现对这一部分的相关学习和体会做一下整理,内容参考 深入剖析Kubernetes 原文,仅作为自己后续回顾方便 希望详细了解的同学可以移步至原文支持一下原作者 参考原文:深入剖析Kubernetes 1. PV、PVC、StorageClass 关系梳理 1.1 相关概念 Volume:其实就是将一个宿主机上的目录,跟一个容器里的目录绑定挂载在了一起 持久化 Volume:指的就是
日志对于调试问题和监视集群情况也是非常有用的。而且大部分的应用都会有日志记录,对于传统的应用大部分都会写入到本地的日志文件之中。对于容器化应用程序来说则更简单,只需要将日志信息写入到 stdout 和 stderr 即可,容器默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件之中,同样也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。
在前面的文章中已经分析过 deployment、statefulset 两个重要对象了,本文会继续分析 kubernetes 中另一个重要的对象 daemonset,在 kubernetes 中 daemonset 类似于 linux 上的守护进程会运行在每一个 node 上,在实际场景中,一般会将日志采集或者网络插件采用 daemonset 的方式部署。
Kubernetes对于有状态的容器应用或者对数据需要持久化的应用,不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储卷,而且需要更加可靠的存储来保存应用产生的重要数据,以便容器应用在重建之后仍然可以使用之前的数据。
深入了解 CSI(Container Storage Interface)是什么以及它如何在 Kubernetes(k8s)中工作。
K8s集群中包含两类用户:一类是由 K8s管理的 Service Account,另一类是普通用户。
在企业落地 K8S 的过程中,私有镜像库 (专用镜像库) 必不可少,特别是在 Docker Hub 开始对免费用户限流之后, 越发的体现了搭建私有镜像库的重要性。
描述: 我们在使用Jenkins的时候一般都会分为server节点与agent节点(也可以叫 slave 节点)。
Kubernetes使用ReplicaSet来保证一个服务的实例数量,如果说某个Pod实例由于某种原因挂掉或崩溃,ReplicaSet会立刻用这个Pod的模版新启一个Pod来替代它。由于是无状态的服务,新Pod与旧Pod一模一样。此外Kubernetes通过Service(一个Service后面可以挂多个Pod)对外提供一个稳定的访问接口,实现服务的高可用。
在上一期,我们提到,存储厂商或云存储提供商可以为Kubernetes提供插件,让Kubernetes中的容器可以方便地在自己提供的存储产品或服务中,创建、挂载及销毁持久化卷。这种插件的规范叫做CSI (Container Storage Interface)。
CSI snapshot是由华为在Kubernetes社区主导开发的存储特性,在K8S 1.12进入Alpha阶段。接下来,我们将分为上下两篇,分别介绍snapshot的创建删除等API以及从snapshot还原数据卷,同时,我们将使用CSI hostpath 插件来演示,如何使用这两种特性。
在没有介绍Kubernetes Volume之前,先来回顾下Docker Volume,Docker Volume常用使用方式有两种,
有赞 PaaS 团队自17年7月份开始投入测试资源,测试人员的加入意味着与测试相关的一系列东西产生,比如测试环境、测试工程、测试流程等等,这次分享的内容主要与测试环境有关,刚开始我们把测试环境部署在虚拟机上,从18年7月份开始,我们决定把测试环境从虚拟机迁移到 K8S 上,做这个决定主要出于以下几个方面考虑。
首先,StatefulSet 的控制器直接管理的是 Pod。这是因为,StatefulSet 里的不同 Pod 实例,不再像 ReplicaSet 中那样都是完全一样的,而是有了细微区别的。比如,每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式,就是通过在 Pod 的名字里加上事先约定好的编号。
我们很高兴地宣布发布 Kubernetes v1.30: Uwubernetes,这是迄今为止最可爱的版本!
k8s API服务器在接收到请求后,会经过 1) 认证插件; 如果其中一个认证插件通过,则认证结束。2) 进入授权流程。3) 进入准入控制链,所有注册的注入控制节点全部通过,则准入结束
通过 yaml 或 json 描述 Pod 和其内容器的运行环境以及期望状态,比如一个最简单的 nginx pod 可以定义为:
领取专属 10元无门槛券
手把手带您无忧上云