教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载导读当企业内部应用逐渐增多、依赖关系与部署环境日趋复杂时直接用 YAML 文件管理 Kubernetes 应用的方式将难以满足生产需要。本文以 kubernetes-handbook 仓库中 构建私有 Chart 仓库 一文为骨架结合仓库内 manifests/charts 下的真实 Chart 样例系统讲解 Helm Chart 的组成结构、安装方式与依赖管理并给出两条可落地的私有 Chart 仓库建设路径使用 GitHub Pages 静态托管 Chart 压缩包 index.yaml以及部署 Monocular UI 实现 Chart 的展示与搜索。读完本文你将掌握从 Chart 打包、仓库索引生成、GitHub Pages 发布到helm repo add消费的完整链路并了解 Monocular 的两种部署方式及其踩坑点。为什么需要私有 Chart 仓库Helm 是 Kubernetes 应用的包管理工具地位类似 Ubuntu 的 APT 与 CentOS 的 YUMChart 则是 Helm 管理的应用打包格式。仓库中 使用 Helm 管理 Kubernetes 应用 一文总结了 Helm 与 Chart 的四大核心价值应用程序封装、版本管理、依赖检查、便于应用程序分发。当企业内部应用数量上升后直接使用 YAML 文件管理的方式会遇到两个突出问题互相依赖应用间存在版本耦合缺乏统一的依赖解析与版本约束机制部署环境复杂不同环境测试、预发、生产的配置差异难以用散落的 YAML 文件收敛。因此有必要构建自己的 Chart 仓库统一承载打包后的 Chart 压缩包并最好提供一个前端用于展示和搜索 Chart。原文档给出的目标是构建一个 GitHub Pages 存储所有 Chart 压缩文件并配有前端展示与搜索能力。理解 ChartHelm 的打包与分发单元Chart 是 Helm 管理的应用打包格式具有如下特征Chart 中包含一系列 YAML 格式的描述文件一个 Chart 只用于部署单个应用不应过于复杂不应包含多个依赖相当于一个微服务。Chart 有特定的目录结构可以打包起来进行版本控制。Chart 的组成结构以 nginx 的 Chart 为例其组成结构如下nginx/ Chart.yaml # 必须一个包含chart的名称、版本和启用条件信息等的YAML文件 LICENSE # 可选: chart的许可证 README.md # 可选: 使用说明 requirements.yaml # 可选: 该chart的依赖配置 values.yaml # 必须该chart的默认配置值 charts/ # 可选: 包含该chart依赖的chart templates/ # 可选kubernetes manifest文件模板用于生成kubernetes yaml文件 templates/NOTES.txt # 可选: 该chart的使用说明和提示信息文本文件作为helm install后的提示信息仓库 manifests/charts 目录下就保留了多个结构完整的真实 Chart可作为对照样本。以 mychart 为例其 Chart.yaml 内容为apiVersion: v1 description: A Helm chart for Kubernetes name: mychart version: 0.1.0而 values.yaml 定义了模板渲染所需的默认值包括副本数、镜像仓库与标签、拉取策略、Service 端口映射以及资源限制# Default values for mychart. # This is a YAML-formatted file. # Declare variables to be passed into your templates. replicaCount: 1 image: repository: harbor-001.jimmysong.io/library/nginx tag: 1.9 pullPolicy: IfNotPresent service: name: nginx type: ClusterIP externalPort: 80 internalPort: 80 resources: limits: cpu: 100m memory: 128Mi requests: cpu: 100m memory: 128Mitemplates目录下的 deployment.yaml 与 service.yaml 展示了模板化的工作方式文件中的{{ .Values.xxx }}会在安装/升级时被values.yaml或命令行传入的值渲染替换{{ template fullname . }}、{{ .Chart.Name }}、{{ .Chart.Version }}等则来自 templates/_helpers.tpl 与 Chart 元数据。例如_helpers.tpl中的fullname定义为{{- define fullname -}} {{- $name : default .Chart.Name .Values.nameOverride -}} {{- printf %s-%s .Release.Name $name | trunc 63 | trimSuffix - -}} {{- end -}}可见 Chart 模板底层使用的是 Go template_helpers.tpl集中定义了模板辅助函数values.yaml中的键值通过{{ .Values.service.type }}这类表达式注入到最终的 Kubernetes 清单中。关于模板渲染的详细讲解可参见 使用 Helm 管理 Kubernetes 应用。Chart 的安装方式安装 Chart 主要分为安装本地定义的 Chart 和远程 Chart 仓库中的 Chart 两种方式。安装本地 Chart指定本地 Chart 目录helm install .指定本地 Chart 压缩包helm install nginx-1.2.3.tgz安装 Chart 仓库中的 Chart使用默认的远程仓库helm install stable/nginx使用指定的仓库helm install localhost:8879/nginx-1.2.3.tgz实际上可以将 Chart 打包后作为静态文件托管到 Web 服务器上例如 GitHub Pages 作为 Chart 仓库也可以。仓库中 nginx-ingress 安装文档 就使用了helm package .将本地 Chart 打包这正是将 Chart 发布到仓库前的标准动作。结合 helm.md 的完整命令体系与仓库构建强相关的常用命令包括helm create在本地创建新的 Charthelm dependency管理 Chart 依赖helm package打包本地 Charthelm repo列出、增加、更新、删除 Chart 仓库helm pull拉取远程 Chart 到本地helm search使用关键词搜索 Charthelm install安装 Chart可配合-f myvalues.yaml、--set keyvalue、--set-string、--set-file覆盖默认值helm upgrade/helm rollback升级与回滚 releasehelm uninstall卸载 releasehelm lint检查 Chart 配置是否有误。依赖管理有两种方式来管理 Chart 的依赖直接在 Chart 的charts目录下定义通过在requirements.yaml文件中定义依赖的 Chart。在每个 Chart 的charts目录下可以定义依赖的子 Chart。子 Chart 有如下特点无法访问父 Chart 中的配置父 Chart 可以覆盖子 Chart 中的配置。仓库中 mean 是一个多 Chart 组合的典型案例其 requirements.yaml 声明了对 MongoDB 子 Chart 的依赖dependencies: - name: mongodb repository: http://localhost:8879 version: 0.4.x对应的 requirements.lock 则锁定了依赖解析结果将mongodb固定到version: 0.4.17并记录了依赖图谱的digest与生成时间dependencies: - condition: enabled: false import-values: null name: mongodb repository: http://localhost:8879/ tags: null version: 0.4.17 digest: sha256:955f80c2844df5fb24c06440898df8d3b2143d7081ac11409d8604720e47b814 generated: 2017-10-24T11:45:19.05411408:00可以看到其依赖的 mongodb Chart 版本正是0.4.17requirements.lock保证了同一份依赖图谱在不同环境下的可复现性。该 Chart 的templates/_helpers.tpl中还额外定义了mongodb.fullname辅助函数说明子 Chart 拥有独立的命名空间与模板上下文。Chart 仓库的本质Chart 仓库repository是一个用来托管index.yaml文件和打包好的 Chart 文件的 Web 服务器。当前 Chart 仓库本身没有设置身份和权限验证官方 issue 对此问题的进展一直在跟进详见原文档所引 kubernetes/helm#1038。因为 Chart 仓库只是一个 HTTP 服务通过 HTTP GET 获取 YAML 文件和 Chart 的压缩包所以可以将这些文件存储在 Web 服务器中例如 GCS、Amazon S3、GitHub Pages 等。关于 Chart 仓库的更多信息请参考 Helm Chart 官方文档。使用 GitHub Pages 托管 Charts既然 Chart 仓库本质上只是静态文件托管那么用 GitHub Pages 做存储是完全可行的。整体思路如下打包 Chart对本地 Chart 目录执行helm package .生成nginx-1.2.3.tgz这样的压缩包仓库中 nginx-ingress 安装文档 即示范了该命令的实际用法生成索引将多个 Chart 压缩包放入同一目录后执行helm repo index .生成仓库索引index.yaml其中记录了每个 Chart 的下载地址、版本、校验和等元数据发布到 GitHub Pages将 Chart 压缩包与index.yaml提交并推送到 GitHub 仓库的gh-pages分支或配置为 Pages 的目录即可获得一个静态托管的 Chart 仓库地址在 Helm 中新增 repo执行helm repo add myrepo https://username.github.io/repo之后即可通过helm search、helm install myrepo/chart消费该仓库。此外Helm 2 时代还提供过本地 HTTP 仓库方案。仓库中 ceph-helm 安装指南 就记录了本地 repo 的用法$ helm serve $ helm repo add local http://localhost:8879/charts上述localhost:8879正是 mean/requirements.yaml 中依赖仓库地址http://localhost:8879的由来。需要说明的是helm serve属于 Helm 2 的功能Helm 3 已将其移除团队自建仓库时建议直接采用静态托管方案GitHub Pages、对象存储等配合helm repo index它们对 Helm 3 完全兼容。构建 Monocular UIChart 仓库只有原始文件还不够直观Monocular 是一个开源的 Kubernetes Helm Chart 浏览器提供 Chart 的展示、搜索与安装入口。克隆项目到本地git clone https://github.com/kubernetes-helm/monocular.git依赖环境Monocular UI 基于以下技术栈构建Angular 2angular/cliTypescriptSassWebpackBootstrap在monocular/src/ui目录下执行以下命令安装依赖yarn install npm install -g angular/cli npm install -g typescript npm install -g webpack运行使用 docker-compose最简单的运行方式是使用 docker-composedocker-compose up该命令需要用到如下镜像bitnami/mongodb:3bitnami/node:8quay.io/deis/go-dev:v1.5.0原文档特别提示这个过程会有一个很长的 build 过程且构建失败。这意味着 docker-compose 方式在当时的环境下并不可行需要改用下面的 Helm 部署方式。运行使用 Helm首先需要已在本地安装了 Helm并在 Kubernetes 集群中安装了 tiller对应部署环境请先阅读 使用 Helm 管理 Kubernetes 应用其中包含 Helm 安装、Chart 创建与常用命令的完整说明。# 需要安装 nginx ingress $ helm install stable/nginx-ingress $ helm repo add monocular https://kubernetes-helm.github.io/monocular $ helm install monocular/monocular部署完成后即可打开 Monocular 界面查看 Chart 列表。不过原文档记录了一个真实踩坑点由于 nginx ingress 配置问题官方 Chart 中api与ui使用的是同样的 domain name作者当时使用的是 traefik ingress导致api访问不到因此加载不了 Chart。这提示我们在生产使用 Monocular 时需要额外注意 ingress 路由规则api与ui必须分别配置可解析的域名或路径规则否则前端无法从后端 API 拉取 Chart 数据。小结与参考本文完整覆盖了私有 Chart 仓库建设的三个层次理解 Chart 结构打包单元、目录组成、安装方式、依赖管理、搭建仓库底座利用 GitHub Pages 静态托管 index.yaml索引、增强体验Monocular UI 的展示与搜索。仓库中 manifests/charts 下的 mychart、mongodb、mean、oam-core-resources 等真实 Chart 可以作为构建与验证的样本helm.md 提供了 Helm 命令体系的完整速查ceph-helm 安装指南 则展示了本地 repo 方案在企业实践中的真实用法。进一步参考Monocular UI 官方仓库kubernetes-helm/monocularUsing a private github repo as helm chart repo (https access)仓库内 使用 Helm 管理 Kubernetes 应用、ceph-helm 安装指南、manifests/charts 目录赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Helm仓库管理指南私有Chart仓库搭建与维护Helm仓库管理指南私有Chart仓库搭建与维护 前言为什么需要私有Chart仓库 在Kubernetes生态中Helm作为事实上的包管理标准极大地简云原生容器编排CLI运维Helm企业级Chart仓库搭建私有化应用分发平台Helm企业级Chart仓库搭建私有化应用分发平台 引言 在KubernetesK8s容器编排系统环境中应用的部署和管理面临着诸多挑战如版本控制复杂云原生容器编排CLI运维在 Kubernetes 上使用 Helm Chart 部署 MEAN 应用kubernetes-handbook 中的 mean Chart 实战指南在 Kubernetes 上使用 Helm Chart 部署 MEAN 应用kubernetes handbook 中的 mean Chart 实战指南 导读教程云原生容器编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考