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)