KubeSphere的知识点
# KubeSphere的知识点
## 为什么需要密钥和凭证?
> **因为有些配置文件需要配置某些应用的用户名和密码, 如果我们将用户名或密码直接写上去, 而且这个项目是开源的, 那么, 这些用户名和密码就会造成泄漏, 因此, 为了避免泄漏, 所以引入了密钥和凭证**
### 创建MySQL的密钥[保密字典]
![image.png](https://cos.easydoc.net/13568421/files/ln2xzob1.png)
![image.png](3)
### 创建凭证
[**官方教程**](https://v3-2.docs.kubesphere.io/zh/docs/devops-user-guide/how-to-use/credential-management/#%E5%88%9B%E5%BB%BA-docker-hub-%E5%87%AD%E8%AF%81)
> 注意: 这里需要我们去创建一个阿里云的镜像仓库, 还有生成一个Gitee的访问令牌, 这里我不演示了, 还有, **sonarqube的那个密钥是之前整合sonarqbe的密钥, 别丢了**
#### kube-config的凭证信息丢失
> 在新版的KubeSphere中, 默认是获取不到凭证信息的, 按照下面的文档, 获取凭证信息并赋值[**官方文档**](https://v3-2.docs.kubesphere.io/zh/docs/multicluster-management/enable-multicluster/retrieve-kubeconfig/)
![image.png](https://cos.easydoc.net/13568421/files/ln30isze.png)
## PV | PVC是什么?
![image.png](https://cos.easydoc.net/13568421/files/ln2xogfv.png)
> **我的理解: PV相当于一个磁盘空间资源, 而PVC类似于开辟磁盘空间资源的一条指令, 我们可以给Pod分配PVC, 通过PVC给他分配PV, 让某个Pod具有持久化数据的能力, 避免Pod容灾恢复导致的数据丢失**
# DevOps
## 什么是DevOps
![image.png](https://cos.easydoc.net/13568421/files/ln2yfhkh)
- DevOps: Development 和 Operations 的组合
- DevOps 看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。
- 突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
- DevOps 希望做到的是软件产品交付过程中 IT 工具链的打通,使得各个团队减少时间损耗,更加高效地协同工作。专家们总结出了下面这个 DevOps 能力图,良好的闭环可以大大增加整体的产出。
> 我的理解, 当开发者开发完代码之后, 我们需要经历一系列操作才能将项目真正的上线, 上线之后才能交给运维人员, 而上线的步骤比较繁琐, 如果, 全都人工操作, 整体上线效率很低, 为了打破这个上线壁垒, 就出现了DevOps
## 什么是CICD?
![image.png](https://cos.easydoc.net/13568421/files/ln2ynmem.png)
### 1. 持续集成(Continuous Integration)
- 持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。
- CI 需要具备这些:
- 全面的自动化测试。这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;
- 灵活的基础设施。容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;
- 版本控制工具。如 Git,CVS,SVN 等;
- 自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;
- 反馈机制。如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。
### 2. 持续交付(Continuous Delivery)
>持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。
灰度发布, 持续交付和持续集成的优点非常相似:
- 快速发布。能够应对业务需求,并更快地实现软件价值。
- 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;
- 高质量的软件发布标准。整个交付过程标准化、可重复、可靠,
- 整个交付过程进度可视化,方便团队人员了解项目成熟度;
- 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。
### 3. 持续部署(Continuous Deployment)
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
> “开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测
试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体
验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。
> “You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。
#### 持续交付的工具链路图
![image.png](https://cos.easydoc.net/13568421/files/ln2z66n1)
### 理解
> 持续集成包括这几个步骤: 代码拉取, 代码编译, 代码测试, 代码质量分析
> 持续交付包括这几个步骤: 镜像创建, 镜像提交(快照), 部署开发环境
> 持续部署包括这几个步骤: 部署生产环境, 镜像与代码都发布正式版
### 落地方案
> **Gitee + Jekins + Maven + Docker**
## Jenkins
### Jenkins介绍
[**官方文档**](https://jenkins.io/zh/doc/pipeline/tour/getting-started/)
Jenkins 是开源 CI&CD 软件领导者, 提供超过 1000 个插件来支持构建、部署、自动化, 满足任何项目的需要
![image.png](https://cos.easydoc.net/13568421/files/ln3459ug)
> 用Jeknins来实现整个CICD的流程
### 流水线的流程图
![image.png](https://cos.easydoc.net/13568421/files/ln34cnji.png)