CNCF生态圈部署监控（告警）日志CI/CDCI/CDKuberentes基本介绍1. 如何部署一个Kubernetes集群2. 为什么使用Kubernetes3. Kubernetes基本概念介绍1) Master2) Work Node3) Pod4) Deployment5) Service4. 基于Kubernetes的蓝绿发布和滚动发布集成Kubernetes的Jenkins1. Jenkins2. 结构图3. 相比传统模式的优点其他相关组件1. Harbor2. Helm/ ChartCI Pipeline1. 多种流水线场景2. 流程图

CNCF生态圈

云原生基金会(CloudNativeComputingFoundation-CNCF) (https://landscape.cncf.io/images/landscape.png)

CNCF是Linux基金会下的非营利组织，最早是由Google、Redhat等开源巨头提议发起，目前已经有百余家的企业会员，它的核心一定是Kubernetes，所以它的目的是也是希望以K8S位基础，由各家开源基础设施厂商主导的平台级的社区。

部署

• Ingress
• Helm
• Rook Ceph

监控（告警）

• Prometheus/ Alert Manager
• Grafana

日志

• Fluentd/ Fluent-bit
• Elasticsearch/ Kibana

CI/CD

• Jenkins
• GitLab CI

CI/CD

• 敏捷开发 -> 敏捷部署
• 开发高质量的代码 -> 代码质量扫描/ 单元测试高覆盖率
• 足够健壮的自动化测试用例 -> 并行高效
• 完整的持续集成和持续部署流程 -> 日志、监控、弹性伸缩、快速回滚、蓝绿发布、高可用

Kuberentes基本介绍

Kubernetes 是一个跨主机集群的开源的容器编排服务以及调度的平台

1. 如何部署一个Kubernetes集群

• 公有云
• AWS EKS
• Azure AKS
• Google GKE
• Aliyun ACK
• 本地环境
• Minikube / Docker Desktop (dev)
• Kubeadm (单节点/ 高可用)/ Kops/ SaltStack

2. 为什么使用Kubernetes

• 多平台：linux/ Windows/ 公有云平台
• 服务发现和负载均衡
• 自动修复/ 横向的自动扩容
• 多种持久化存储的支持(Local/ Ceph/ NFS/ AWS EBS…)
• 滚动更新/ 蓝绿发布以及快速回滚
• 基于角色的权限访问控制（RABC）的权限访问控制
• 资源的监测
• 应用健康检查(liveness probe/ readiness probe)
• 松耦合以及可扩展，天然适用于微服务架构(Service Mesh，Istio)
• 丰富的云原生生态圈(Prometheus、Fluent-bit、Nginx…)

3. Kubernetes基本概念介绍

1) Master

Master节点主要包括了四个模块：

• apiserver – 对外暴露和提供Restful的API服务，也是外界调用的入口(比如本地的kubectl指令)
• scheduler – 负责pod的调度，根据资源和策略将pod调度到合适的node上
• controller-manager – 集群的控制管理中心，当集群发生节点宕机，会自动进行修复，来确保所有的Pod的是预期的状态
• etcd – 高可用的分布式键值数据库，用来存储k8s各个资源的状态，是集群的持久化数据

2) Work Node

Node是Kubernete的工作节点，可以是一个虚拟机或者物理机，所有的Node都是通过master来进行管理，Node上主要的模块有三部分：

• runtime -容器运行环境，我们主要使用的是docker，当然也有其他的选择
• kubelet – 最重要的计算核心，维护和管理Node上所有的容器
• kube-proxy – 该模块实现了k8s的自动服务发现功能

3) Pod

Pod是Kubernetes里的原子调度单位和最小的编排单位，Kubernetes是按照Pod为单位而不是容器为单位去进行资源调度的，Pod和容器的区别在于，Docker本质实际是一个单进程，Pod可以运行多个容器，这些容器进程之间共享网络和文件系统。

对于某些需要互相进行直接文件交换，通过localhost进行本地网络通讯，非常频繁的远程调用等紧密协作的容器，适合放在一个Pod中，这样会使得访问和运行更加高效。这种模式目前最主流的就是sidecar边车模式，比如说我们会在应用的Pod中再启动一个容器去做一些独立于主进程之外的工作，比如说容器日志的收集，或者是一个代理proxy应用，比如Istio 项目使用 sidecar 容器完成微服务的管理。

但是对于某些虽然有相互关联，比如Java应用程序和MySQL数据库程序，我们需要更好的高可用和松耦合，就没有必要放在一个Pod中，更加适合做个两种类型的Pod。

4) Deployment

Deployment是K8S控制器的一种，也是最基础的类型，首先我们讲一下为什么需要Deployment。

K8S中的Pod是无状态的，一旦Pod被删除了或者挂了，它们的生命周期也就结束了，所以如果想要管理无状态的Pod应用，并且想要实现Pod个数弹性伸缩/自动修复/滚动升级/历史版本回滚等功能，我们就需要Deployment控制器，我们只需要在Deployment中描述我们需要Pod的目标状态，那么K8S就会一直保证Pod处于我们期待的状态，即使Pod被不小心删除了甚至Node节点宕机了，K8S也能快速恢复我们在Depoloyment中定义的内容。

5) Service

一个应用服务会有一个或者多个实例Pod，每个Pod的IP都是随机分配的，重启后会改变，如果我们需要通过一个固定的IP地址（服务名）和端口以负载均衡的方式访问它们，就需要Service。

Service是一个抽象的逻辑概念，它定义了一个服务的访问入口地址，Service与后端的一组Pod实例之间是通过Label Selector来实现关联的。

Service有固定的内部服务名IP和端口，但是默认是只能在集群内部访问。

如果我们想要把Service暴露到公网，有如下几种方式：

• NodePort (把Service的端口映射到工作节点上，如果不指定，会在30000-32767之间随机选择一个)
• LoadBalancer
• Ingress

举一个NodePort类型Service的例子如下：

4. 基于Kubernetes的蓝绿发布和滚动发布

集成Kubernetes的Jenkins

1. Jenkins

• 强大的第三方插件支持
• 主从分布式结构
• 界面和Jenkinsfile Pipeline配置方式
• Blue Ocean流水线界面
• 和CloudNative以及Kubernetes的紧密结合

Blue Ocean流水线

Jenkins 是目前最主流的持续集成和持续部署工具，它之所以一直流行并且强大的最主要原因就是通过各种插件方式来进行功能的扩展，从而满足开发测试繁多的需求。

Jenkins 本身的结构是分布式主从结构，可以有多个从节点，主节点可以只用于进行管理， 运行任务的负载可以分布到不同的节点上，并且多个节点可以是不同的系统不同的环境，分布式结构可以支持大规模的任务的以及需要多环境的项目。

对于刚接触的用户，Jenkins提供基于界面配置的模式，并且还有比较完善的文档，非常易于上手工作，当然目前Jenkins最主推的还是 Pipeline 流水线的模式，通过脚本的方式来定义Pipeline流水线，并且提交到git仓库进行版本管理，Jenkins官方还开发了全新的流水线界面 Blue Ocean，能够更加直观的体现出CICD整个流水线过程。

Jenkins是基于Java开发的应用，目前支持多种平台的快速安装，包括Windows/ Mac/ Linux/ Docker以及Kubernetes集群。

最近Linux基金会和Google等公司共同推出了一个新的开源软件基金会，叫做持续交付基金会(CDF)，CDF致力于培育和维护开源的持续集交付生态系统，

Jenkins也是加入其中的最早一批成员之一，并且推出基于云原生和Kubernetes的CI/CD平台JenkinsX，说明Jenkins也在努力往Cloud和Kubernetes方向靠近，并且进行更加密切的集成，这也是我们选择使用基于K8S平台运行Jenkins服务的原因。

2. 结构图

3. 相比传统模式的优点

• 快速搭建以及数据持久化

  通过官方的Helm Chart可以快速搭建出Jenkins的主节点，并且可以通过NFS，Ceph，AWS EBS或者映射到宿主机等，将Jenkins的数据进行持久化存储

• 高可用

  Jenkins官方只支持单点Master节点，没有比较好的高可用的方案，如果单点故障了，K8S会快速重新启动一个新的Jenkins Master服务，并且挂载之前已有的存储盘，不会造成数据的丢失

• 动态Slave节点

  动态创建Slave节点，并且任务完成后会删除Slave节点，自动释放资源，而且K8S会根据每个Node的资源使用情况，动态合理分配 Slave 到空闲的Node上，从而使资源更加合理的被分配和使用

• 基于不同镜像的Pipeline

  每个Slave Pod都是通过启动一个Docker镜像来执行具体的任务，一个Pipeline可以调用多个镜像来完成不同语言环境下的编译打包测试等任务，相比较传统模式要手动创建和维护多套环境，则更加方便和更加具有隔离性

举一个使用不同镜像模板的Pipeline的例子：

其他相关组件

1. Harbor

An open source cloud native registry project

• 支持Docker镜像以及Helm Chart的上传下拉和管理
• 基于角色（RBAC）的访问控制
• 支持与LDAP/AD集成，用于用户身份验证和管理
• 漏洞扫描
• 镜像的复制(高可用)
• 友好的界面展示

2. Helm/ Chart

Helm工具帮助我们管理Kubernetes应用，不管应用如何复杂，都可以通过定义好的Helm Chart来快速便捷的安装、升级应用。

Helm Chart还可以进行版本管理， 分享以及上传到相应的仓库中

CI Pipeline

1. 多种流水线场景

• 代码提交自动触发部署和自动化测试

• 可配置化的快速手动部署环境(用于业务测试以及开发自测)

• Jenkins的Multiple Branch可以对稳定分支的环境自动进行更新和维护

2. 流程图