Helm 及Helm 应用仓库简介李辉— KubeSphere - 云原生实战云原生实战 Helm 及 Helm 应用仓库简介 李辉 — KubeSphere — 后端研发 _ by QingCloud Helm 及其应用仓库简介 如何开发一个 Helm 应用 KubeSphere 应用开发 1 2 3 _ by QingCloud 应用管理 5 应用仓库管理 4 Helm 及其应用仓库简介 • Helm 是 Kuberetes 的包管理器 类似于 应用程序的一系列 YAML 文件 • 安装 Helm 在 https://github.com/helm/helm 上下载二进制文件 _ by QingCloud Helm 及其应用仓库简介 • 应用仓库: 管理和分发 Helm Charts. • 安装 Harbor 1. helm repo add harbor https://helm.goharbor.io 2. helm fetch Chart 推送到应用仓库 _ by QingCloud KubeSphere 应用开发 • 应用生命周期: • 开发中: 开发中的 • 待发布: 已开发完成,等待应用商店管理员审核通过 • 已审核通过: 应用商店管理员审核通过 • 审核未通过: 应用商店管理员审核通过 • 已上架: 已经上架到应用商店 • 已下架: 从应用商店下架 _ by QingCloud 应用仓库管理 • 添加应用仓库0 码力 | 9 页 | 2.48 MB | 1 年前3
14-Chaos Mesh 在网易伏羲私有云自动化故障注入实践-张慧Chaos Mesh 在网易伏羲私有云自动化故障注入实践 Speaker Name:张慧 网易伏羲 Speaker Title:网易伏羲私有云质量保障负责人、Chaos Mesh 布道师、云原生社区 Stability SIG 发起人 Email:zhangui05@corp.netease.com 云 原 生 学 院 目录 网易伏羲私有云简介 为什么混沌测试 什么是混沌测试 什么是混沌测试 如何选择混沌测试工具 为什么是 Chaos Mesh Chaos Mesh 在网易伏羲的实践 网易伏羲私有云简介 网易伏羲私有云简介 AI 模型 支撑游戏业务 云游戏 为什么混沌测试 为什么混沌测试 为什么混沌测试 理想下,系统用不 宕机,100%可用 比如机房突然断电 事故突然的到来 为什么混沌测试 通用指标 For FuXi , 结合流量回放在测试环境真实模拟用户流量;或真实线上集群上混沌; For Chaos Mesh , 通用组件的开箱即用;比如 Redis、Kafka等等 欢迎对混沌测试,对私有云稳定性感兴趣的同学一起关注云原生社区 stability SIG 、 Chaos Mesh 社区和网易伏羲 ~ 云原生社区 THANKS0 码力 | 25 页 | 3.33 MB | 6 月前3
云原生安全威胁分析与能力建设白皮书(来源:中国联通研究院).......................................................................................21 2.2.2 镜像仓库攻击........................................................................................22 2.2.3 ......................................................................................38 3.2 挂载 Docker Socket 导致容器逃逸攻击..................................................38 3.2.1 攻击场景介绍............... 、王琦、汤旭、雷新、 浦明、张小勇、白黎明、左伟震、范璟玮、许秀莉 云原生安全威胁分析与能力建设白皮书 9 一、云原生安全概述 近年来,云计算技术一直处于高速发展的过程中,并且随着公有云和私有云 的广泛应用,利用云计算作为承载业务运行的基础设施,已经成为了企业的首选。 “十四五”时期,中国的信息化进入加快数字发展、建设数字中国的新阶段,在 数字化转型的浪潮中,云计算作为新型数字基础设施和新一代信息技术的核心引0 码力 | 72 页 | 2.44 MB | 1 年前3
09-harbor助你玩转云原生-邹佳steven zou 目录 - 开场:云原生与制品管理 - 初识Harbor:云原生制品仓库服务 - 使用Harbor搭建私有制品仓库服务 - 资源隔离与多租户管理模型 - 制品的高效分发(复制、缓存与P2P集成) - 制品的安全分发(签名、漏洞扫描与安全策略) - 资源清理与垃圾回收 - 构建高可用(HA)制品仓库服务 - Harbor集成与扩展 - 路线图 - 参与贡献Harbor社区 云原生与制品管理 云原生与制品管理 [1] 云原生(cloud-native)技术使组织能够在现代化和动态的环境下(如公有云、私有云 和混合云)构建和运行可扩展的应用程序。云原生典型技术包括容器、服务网络、 微服务、不可变基础设施和声明性API等。 v1.0 by CNCF 容器-更轻量级和灵活的虚拟化 镜像-应用软件打包与分发 OCI: https://opencontainers.org/ OCI制品(artifact):镜像,Helm [2] Registry: •制品存储仓库 •分发制品的媒介 •访问控制与管理的节点 初识Harbor [1] 官方网站:goharbor.io CNCF毕业项目 落地在很多企业级 产品中 Apache 2.0协议下 开源 GitHub代码库: https://github.com/goha rbor/harbor/ 一个开源可信的云原生制品仓库项目用来存储、签名和管理相关内容。0 码力 | 32 页 | 17.15 MB | 6 月前3
23-云原生观察性、自动化交付和 IaC 等之道-高磊-1-引子 客户环境交付 制品 • 云应用交付最难的还不是RT的 碎片化,最难的是环境依赖的 碎片化,比如,硬件环境、网 络环境、运维规范等的碎片化。 尤其是运维方面的差异化,必 然导致私有Paas的出现! • 虽然服务网格、虚拟化等正在 努力解决交付困难的问题,但 是依然对除RT外的环境依赖碎 片化无能为力。 • 背后的原因在于特定环境依赖或者运维规范问题渗透到了PaaS本身, 标准化能力-微服务PAAS-OAM-万花筒PAAS-3 以上解耦的结果,隐含着更深层次的能力,不是简单解耦那么简单,它使得统一通用PaaS成为可能 组件市场|仓库 平台运维特性 应用编排 运维特性编排 版本化 应用 • 两端解耦之后,两端方面都可以形成一个没有 私有PaaS特征依赖的市场,而强大的开源社区 比平台提供商自己还要强大,利用容器底座的 承载能力和OAM抽象化编排能力,可以不等排 期的构建各种特征的Paas。业务应用由于不依 使用和底层执行体, 进一步加强了统一性。 标准化能力-微服务PAAS-OAM交付流程模式-抽象流程 • 基于CICD和服务市场,通过OAM 集群镜像式打包的方式向团队、 组织或者公司进行整体化交付, 并通过Docker+SDN+云原生存储 +K8S+OAM彻底隔离了不同环境 底层的细节和差异,可以整体化 交付到这些组织所在的数据中心 里去 标准化能力-微服务PAAS-OAM交付流程模式-场景流程 • 由于互联网迭代相对于其0 码力 | 24 页 | 5.96 MB | 6 月前3
中国移动磐舟DevSecOps平台云原生安全实践发过程 统一代 码仓库 依赖制 品仓库 统一 镜像库 云原生 验证环境 磐基 生产运行 核心价值 核心能力 灵活的低代码能力 实现页面组件、数据组件、功能组件的快 速编排,一线人员也能自助开发功能 双模敏态管理 以敏捷研发为引导,融合瀑布式管理需求, 形成普适、灵活的研发过程管理能力。 多用途制品库 兼容市面绝大多数开发语言制品,提供公 用、内部共享、私有等多种使用方式。兼 用、内部共享、私有等多种使用方式。兼 容市面上制品管理客户端。 全功能云IDE开发 每个云IDE都是一个云端小笔记本,一人一 本,多人可形成云端小局域网。可独立编 写调试代码,可团队协作。 安全代码仓库托管 统一的安全代码仓库,按项目级别分级管 理,落盘加密,云IDE防护,显示水印等多 重防护。 云原生虚拟化开发集群 利用虚拟化技术实现开发集群,分钟级交 付,突破有限资源开发集群供给。 原生使用模式,开发组件一键部署 100%流程覆盖 ü 建立资产台账 ü 分类分级标记 ü 关联责任人 ü 关联内外网业务 ü 漏洞及投毒检测 ü 自主可控率分析 ü 许可证合规分析 ü 自动化修复技术 ü 安全可信私有源 ü 供应链准入审查 ü 供应链准出机制 ü 过程持续验证 !"#$%&'( !"#$)*+,- !"#$%&' 安全开发-代码扫描SAST 源代码审计针对源代码缺陷进行静态分析检0 码力 | 22 页 | 5.47 MB | 1 年前3
36-云原生监控体系建设-秦晓辉关注网络IO的情况,因为多个容器共享Pod的net namespace,Pod内多个容器的网络数据相同 • 容器的监控数据可以直接通过 docker 引擎的接口读取到,也可以直接读取 cAdvisor 的接口,Kubelet 里 内置了cAdvisor,cAdvisor 不管是 docker 还是 containerd 都可以采集到,推荐 { 抓取方案一 } • 左侧这个配置大家在网上比较容易搜到,通过ku (prometheus协议) • Kubelet 的核心职责就是管理本机的 Pod 和容器,典型的比如创建 Pod、销 毁 Pod,显然我们应该关注这些操作的 成功率和耗时 • Categraf 的仓库中 inputs/kubernetes/kubelet-metrics- dash.json 就是 Kubelet 的大盘文件 • kubelet_running_pods:运行的Pod的数量,gauge类型 暴露监控数据, 可以直接拉取 • kube-proxy 的核心职责是同步网络规则, 修改 iptables 或者 ipvs。所以要重点关 注 sync_proxy_rules 相关的指标 • Categraf 的仓库中 inputs/kubernetes/kube-proxy- dash.json 就是 kube-proxy 的大盘文件 • up 关注 kube-proxy 的存活性,应该和 node 节点的数量相等0 码力 | 32 页 | 3.27 MB | 6 月前3
22-云原生的缘起、云原生底座、PaaS 以及 Service Mesh 等之道-高磊器 , 而 资 源 隔 离 能 力 早 在 1 9 7 5 年 就 已 经 存 在 2003年Docker兴起,但云原生架构依然 没有出现,Docker公司还差点死了 1 9 9 6 年 戴 尔 提 出 云 计 算 理 念 2006年亚马逊率先推出 了弹性计算云(EC2) 分水岭 云原生 Docker: 抽象云资源,使 得更容易使用 微服务: 加快业务迭代更新 从支持应用不同维度发展,最终走在了一起 客户群体与规模 电信 制造 金融 服务业 政府 互联网 350.2亿 云原生采用规模占比与市场总规模 58% 11% 10% 8% 5% 5% 数据来源:中国云原生产业联盟2019 私有云市场规模 645.2亿 投 入 技 术 运 维 纳 管 规 模 9%客户投入占总IT投 入的一半以上 成为主要支出方向 中心集群规模为主 部署形态多元化、多云/混合云架构成为主流 自动化 用户软件发布方 数 算 数 用 云原生赋能平台 标准化能力-分布式操作系统核心-容器服务 向上提供抽象化自愈IT运营视角 高效稳定应用资源供给 价值主张 架构 云原生底座=控制器+调度器的组合+Docker=根据环境的变化而动+基于封装 一致性的大规模分发 服务编排基本原理: • 以度量为基础,以NodeSelector算法来 决定在哪儿部署容器服务 • 运行时以期望与实际的差别进行动态调 整到期望的状态0 码力 | 42 页 | 11.17 MB | 6 月前3
云原生图数据库解谜、容器化实践与 Serverless 应用实操Tekton 管理镜像制作流⽔线 1. 获取源代码 2. 制作镜像 3. 上传镜像 如何管理 Build pipeline? K8s 弃⽤ Docker 作为 Container Runtime 不能再以 Docker in docker 的⽅式以 Docker build 构建镜像 还有什么选择? Function Build 如何在这些⼯具直接进⾏选择和切换? Cloud Native OpenFunction 社区 交流、参与、演进 OpenFunction Roadmap OpenFunction Community → https://github.com/OpenFunction 主要仓库 → https://github.com/OpenFunction/OpenFunction → https://github.com/OpenFunction/functions-framework 官⽹:⽤户案例 ⼀个可靠的分布式、线性扩容、性能⾼效的图数据库 世界上唯⼀能够容纳千亿顶点和万亿条边,并提供毫秒级查询延时的图数据库解决⽅案 云原⽣时代的图数据库 容器化部署演进 Nebula Docker Nebula K8s Nebula Operator Nebula Operator 实现 Kubebuilder Scaffold CRD Control Loop Calling0 码力 | 47 页 | 29.72 MB | 1 年前3
16-Nocalhost重新定义云原生开发环境-王炜Kubernetes 的普及,进⼀步屏蔽了“微服务”应⽤的复杂度,这主要体现在部署和运维阶段。 为了解决微服务应⽤在开发、测试和⽣产阶段环境⼀致性的问题,现代的微服务应⽤开发,都会将每⼀个组 件打包成 Docker 镜像,并以⼯作负载的形式对其进⾏部署。利⽤ DevOps 流⽔线中的持续集成和持续部署, 配合 Kubernetes 探针、HPA、应⽤⾃愈的能⼒,彻底解放了微服务应⽤的部署和运维环节。 但我们忽略了⼀个关键节点:开发阶段 等即可快速启动微服务应⽤。 但对于开发⼈员来说,原来单体应⽤的开发体验变得不复存在,由于应⽤很难在 Docker 容器之外运⾏,所以 每次代码修改,都需要经历以下步骤: 执⾏ docker build 构建镜像 执⾏ docker tag 对镜像进⾏标记 执⾏ docker push 推送镜像到仓库 修改 Kubernetes ⼯作负载的镜像版本 等待镜像拉取结束 等待 Pod 重建 查看修改后的代码效果0 码力 | 7 页 | 7.20 MB | 6 月前3
共 19 条
- 1
- 2













