本文只涉及Helm的Chart操作,不会对其他知识进行过多描述.至于安装这块,麻烦自行百度吧,一大堆呢. 在容器化的时代,我们很多应用都可以部署在docker,很方便,而再进一步,我们还有工具可以对docker进行编排,Kubernetes就是一个很好的工具.再再进一步,Kubernetes出现了helm,可以将多个服务更好的编排组合成一个应用. Helm Helm的作用相当于node.js下的npm,对于应用发布者而言,可以通过Helm打包应用,管理应用依赖关系,管理应用版本并发布应用到软件仓

Sovereign Systems是一家成立于2007年的技术咨询公司,帮助客户将传统数据中心技术和应用程序转换为更高效的.基于云的技术平台,以更好地应对业务挑战.曾连续3年提名CRN,并且在2012年到2016年均被评为美国增长最快的私营公司之一. 本文由Sovereign Systems的解决方案架构师Chip Zoller根据客户的使用案例撰写而成.   Rancher是一个容器编排管理平台,它已经在这一领域深耕几年并且具备很多简单易用的实用功能.近几年,它经过重构已经完全拥抱Kubern

作为k8s现在主流的一种包部署方式,尽管不用,也需要进行一些了解.因为,它确实太流行了. 这一套太极拳打下来,感觉helm这种部署,目前还不太适合于我们公司的应用场景.它更适合需要手工编程各种yaml文件,使用模板减少工作量和出错. 而我们已实现了web方式的yaml文件编辑,使用Helm意义不大,只能起到优化yaml存储的作用,但同时会使我们的配置文件深度依赖helm. 一,Helm用途 Helm把Kubernetes资源(比如deployments.services或 ingress等) 打

一.概述 1.我们说过在helm架构中有这么几个关键组件,helm,tiller server,一般托管运行于k8s之上,helm能够通过tiller server在目标k8s集群之上部署应用程序,而后,helm对应程序部署来自于helm能访问到的仓库中的chart.并且我们可以把chart通过配置生成为 Release,其中config是来自于我们chart中的values.yaml文件,对chart来讲其内部没有太多复杂的地方,无非就是把我们此前所自己编写的配置清单改写为可复用格式,所谓的可

前文我们介绍了helm的相关术语和使用helm安装和卸载应用,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14305902.html:今天我们来介绍下自定义chart以及打包chart,helm其他命令使用和私有helm仓库搭建相关话题: 继上一篇博客,我们了解了使用helm在k8s上安装应用,卸载应用,以及仓库的添加删除更新等等操作:对于helm chart来说,它就是一个打包文件,把我们需要用到的配置清单,以模板的形式发布出来,用户使用时,可以根据

项目初探 项目地址: 原项目:https://github.com/lonng/nanoserver 调过的:https://github.com/Kirk-Wang/nanoserver 这将是一个完整的,完全践行 DevOps/GitOps 与 Kubernetes 上云流程的 Golang 游戏服务器开发的系列教程. 这个系列教程是对开源项目 Nanoserver 的完整拆解,旨在帮助大家快速上手 Golang(游戏)服务器后端开发.通过实践去理解 Golang 开发的精髓 -- Shar

K8S中的包管理工具 1. 客户端Helm(即Helm)  通过脚本安装:curl https://raw.githubusercontent.com/helm/helm/master/scripts/get > helm.sh,赋权运行: 123456789101112 chmod +x helm.sh./helm.sh# 输出Downloading https://kubernetes-helm.storage.googleapis.com/helm-v2.13.1-linux-amd64.

本节在实践时使用的是 Prometheus Operator 版本 v0.14.0.由于项目开发迭代速度很快,部署方法可能会更新,必要时请参考官方文档. 下载最新源码 git clone https://github.com/coreos/prometheus-operator.git cd prometheus-operator 为方便管理,创建一个单独的 Namespace monitoring,Prometheus Operator 相关的组件都会部署到这个 Namespace. kube

简单的概念介绍: Chart是helm管理的应用的打包格式,一个chart对应一个或一套应用.内部是一系列的yaml描述文件,以为为yaml 服务的文件. 三个部分,helm .tiller.repo .helm,类似于 client,用来执行一些操作命令:tiller,运行依赖k8s环境,接收helm的指令,实际进行集群内部应用的管理:repo,应用的仓库,独立于前两者,提供chart. 1,helm-client下载地址 https://github.com/kubernetes/helm

整体架构 1.为什么要用? 首先在原来项目中都是基于yaml文件来进行部署发布的,而目前项目大部分微服务化或者模块化,会分成很多个组件来部署,每个组件可能对应一个deployment.yaml,一个service.yaml,一个Ingress.yaml还可能存在各种依赖关系,这样一个项目如果有5个组件,很可能就有15个不同的yaml文件,这些yaml分散存放,如果某天进行项目恢复的话,很难知道部署顺序,依赖关系等,而所有这些包括 基于yaml配置的集中存放 基于项目的打包 组件间的依赖 都可以通

目录 一.Prometheus 介绍 1.1.Prometheus 架构 1.2.Prometheus Operator 架构 二.Helm 安装部署 2.1.Helm 客户端安装 2.2.Tiller 服务器安装 三.部署 Prometheus Operator 3.1.安装 Prometheus Operator Deployment 3.2.安装 Prometheus 3.3.安装 Alertmanager 3.4.安装 kube-prometheus 四.查看效果图 4.1.查看 kub

本节在实践时使用的是 Prometheus Operator 版本 v0.14.0.由于项目开发迭代速度很快,部署方法可能会更新,必要时请参考官方文档. 下载最新源码 git clone https://github.com/coreos/prometheus-operator.git cd prometheus-operator 为方便管理,创建一个单独的 Namespace monitoring,Prometheus Operator 相关的组件都会部署到这个 Namespace. kube

一.为什么需要Helm? Kubernetes目前已成为容器编排的事实标准,随着传统架构向微服务容器化架构的转变,从一个巨大的单体的应用切分为多个微服务,每个微服务可独立部署和扩展,实现了敏捷开发和快速部署,但是由于从大一个应用变成了多个微服务,导致服务数大幅增加,对于Kubernetes来说,针对每个服务需要部署如deployment.statufulset.service.pod 等资源文件,而对于一个复杂的应用来说,可能会有很多类似上面的资源文件,其中还有更新或回滚的需求,若要执行,需要修

1.背景 在Kubernetes v1.14版本的发布说明中,kustomize 成为了 kubectl 内置的子命令,并说明了 kustomize 使用 Kubernetes 原生概念帮助用户创作并复用声明式配置. 那么,kustomize 出现的原因是什么?在kustomize的github issue中找到了 kustomize 启发来自一篇Kubernetes声明性应用程序管理,这篇文章内容很多,主要提出了Kubernetes应用的配置规范,声明式配置的优点以及参数化定制配置的缺陷以及一

前言 相信经过前一篇文章的学习,大家已经对Helm有所了解,本篇文章介绍另一款工具 Kustomize,为什么Helm如此流行,还会出现 Kustomize?而且 Kustomize 自 kubectl 1.14以来早已内置到其中,说明官方对其很认可. 我认为还是Helm 参数化模板方式来自定义配置需要学习复杂的DSL语法,难上手,易出错,而 kustomize 是使用 Kubernetes 原生概念帮助用户创作并复用声明式配置. 认识 Kustomize https://kustomize.i

chart repo是一个可用来存储index.yaml与打包的chart文件的HTTP server.当要分享chart时,需要上传chart文件到chart仓库,任何一个能够提供yaml与tar文件的HTTP server都可以当作chart仓库,比如自己的web服务器.官方的chart仓库由kubernetes Charts维护,helm允许我们创建私有的chart仓库. 一个chart仓库由一个chart包与index.yaml文件组成,index.yaml记录了chart仓库中全部ch

# 删除之前创建的 chart helm list helm delete --purge redis1 # 创建自定义 chart myapp cd ~/helm helm create myapp cd myapp/ # 修改 Chart.yaml cat Chart.yaml apiVersion: v1 appVersion: "1.0" description: A Helm chart for Kubernetes myapp chart name: myapp versi

1.开发自己的chart Kubernetes 给我们提供了大量官方 chart,不过要部署微服务应用,还是需要开发自己的 chart,下面就来实践这个主题. 1.1创建 chart 执行 helm create mychart 的命令创建 chart mychart: Helm 会帮我们创建目录 mychart,并生成了各类 chart 文件.这样我们就可以在此基础上开发自己的 chart 了. 新建的 chart 默认包含一个 nginx 应用示例,values.yaml 内容如下: 开发时

chart 是 Helm 的应用打包格式.chart 由一系列文件组成,这些文件描述了 Kubernetes 部署应用时所需要的资源,比如 Service.Deployment.PersistentVolumeClaim.Secret.ConfigMap 等. 单个的 chart 可以非常简单,只用于部署一个服务,比如 Memcached:chart 也可以很复杂,部署整个应用,比如包含 HTTP Servers. Database.消息中间件.cache 等. chart 将这些文件放置在预定

每个成功的软件平台都有一个优秀的打包系统,比如 Debian.Ubuntu 的 apt,Redhat.Centos 的 yum.而 Helm 则是 Kubernetes 上的包管理器. 本章我们将讨论为什么需要 Helm,它的架构和组件,以及如何使用 Helm. 1.Why Helm Helm 到底解决了什么问题?为什么 Kubernetes 需要 Helm? 答案是:Kubernetes 能够很好地组织和编排容器,但它缺少一个更高层次的应用打包工具,而 Helm 就是来干这件事的. 先来看个例