【转】K8S中部署Helm

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.tar.gzPreparing to install helm and tiller into /usr/local/binhelm installed into /usr/local/bin/helmtiller installed into /usr/local/bin/tillerRun ‘helm init‘ to configure helm.

# 验证helm help

注：可能在执行脚本时出现curl: (7) Failed connect to kubernetes-helm.storage.googleapis.com:443; 网络不可达异常信息，多执行几次即可。

2. 服务端Tiller

直接helm init，即可在K8S集群中安装Tiller（在kube-system命名空间中），但执行的时虽然提示成功了，但K8S查看容器状态发现有Failed to pull image "gcr.io/kubernetes-helm/tiller:v2.13.1"....的异常，查看tiller-deployment的yaml文件发现容器的镜像为gcr.io/kubernetes-helm/tiller:v2.13.1，拉不到，去dockerhub上查看谷歌复制镜像命名空间中mirrorgooglecontainers是否有，没有又查看是否有用户镜像docker search tiller:v2.13.1，拉取一个用户的镜像，修改tag、删除旧的（建议在每个节点都干一下，选择器可能没有指定）：

123
 
docker pull hekai/gcr.io_kubernetes-helm_tiller_v2.13.1docker tag hekai/gcr.io_kubernetes-helm_tiller_v2.13.1 gcr.io/kubernetes-helm/tiller:v2.13.1docker rmi hekai/gcr.io_kubernetes-helm_tiller_v2.13.1

再次查看pod已经成功。

tiller授权：

123456789101112131415161718
 
# 设置账号kubectl create serviceaccount --namespace kube-system tillerkubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

# 使用 kubectl patch 更新 API 对象kubectl patch deploy --namespace kube-system tiller-deploy -p ‘{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}‘

# 查看授权是否成功kubectl get deploy --namespace kube-system   tiller-deploy  --output yaml|grep  serviceAccount

serviceAccount: tillerserviceAccountName: tiller

helm version

Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

卸载tiller：helm reset或helm reset --force

3. 使用

创建Helm chart（Helm中的包的形式叫做chart）：

123456
 
# 拉取测试代码git clone https://github.com/daemonza/testapi.git;

cd testapi# 创建chart骨架helm create testapi-chart

生成的chart骨架为：

testapi-chart
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
| ├── service.yaml
│ └── tests
└── values.yaml

其中templates目录中存放的是K8S部署文件的模板，Chart.yaml文件如下：

12345678910
 
# chartAPI的版本，必须只能设为v1apiVersion: v1# 可选参数appVersion: "1.0"# 可选参数description: A Helm chart for Kubernetes# chart的名字，必选参数name: testapi-chart# chart的版本号，必选参数，必须符合SemVerversion: 0.1.0

其中values.yaml文件如下：

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849
 
# Default values for testapi-chart.# This is a YAML-formatted file.# Declare variables to be passed into your templates.

replicaCount: 1

image:  repository: nginx  tag: stable  pullPolicy: IfNotPresent

nameOverride: ""fullnameOverride: ""

service:  type: ClusterIP  port: 80

ingress:  enabled: false  annotations: {}    # kubernetes.io/ingress.class: nginx    # kubernetes.io/tls-acme: "true"  hosts:    - host: chart-example.local      paths: []

  tls: []  #  - secretName: chart-example-tls  #    hosts:  #      - chart-example.local

resources: {}  # We usually recommend not to specify default resources and to leave this as a conscious  # choice for the user. This also increases chances charts run on environments with little  # resources, such as Minikube. If you do want to specify resources, uncomment the following  # lines, adjust them as necessary, and remove the curly braces after ‘resources:‘.  # limits:  #   cpu: 100m  #   memory: 128Mi  # requests:  #   cpu: 100m  #   memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}

可以进入Chart.yaml所在目录运行Chart：

1234
 
cd testapi-chart

# 运行charthelm lint

一切OK的话可以进行打包（在Chart.yaml的父目录外）：

123456
 
# --debug标识可选，加上可以看到输出，testapi-chart是要打包的chart目录，打出的包在当前目录下helm package testapi-chart --debug

# 输出Successfully packaged chart and saved it to: /root/k8s/helm/testapi/testapi-chart-0.1.0.tgz[debug] Successfully saved /root/k8s/helm/testapi/testapi-chart-0.1.0.tgz to /root/.helm/repository/local

现在打包出来在当前目录，也可以直接发布到本地的helm仓库：helm install testapi-chart-0.1.0.tgz，输出如下：

123456789101112131415161718192021222324
 
NAME:   lumbering-zebuLAST DEPLOYED: Fri Apr 26 18:54:26 2019NAMESPACE: defaultSTATUS: DEPLOYED

RESOURCES:==> v1/DeploymentNAME                          READY  UP-TO-DATE  AVAILABLE  AGElumbering-zebu-testapi-chart  0/1    1           0          0s

==> v1/Pod(related)NAME                                           READY  STATUS             RESTARTS  AGElumbering-zebu-testapi-chart-7fb48fc7b6-n6824  0/1    ContainerCreating  0         0s

==> v1/ServiceNAME                          TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)  AGElumbering-zebu-testapi-chart  ClusterIP  10.97.1.55  <none>       80/TCP   0s

NOTES:1. Get the application URL by running these commands:  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=testapi-chart,app.kubernetes.io/instance=lumbering-zebu" -o jsonpath="{.items[0].metadata.name}")  echo "Visit http://127.0.0.1:8080 to use your application"  kubectl port-forward $POD_NAME 8080:80

上述就已经在K8S中创建了deployment，查看默认的命名空间就可以发现多了一个lumbering-zebu-testapi-chart的Deployment，可以查看deployment的包：

12345
 
helm ls

# 输出NAME          	REVISION	UPDATED                 	STATUS  	CHART              	APP VERSION	NAMESPACElumbering-zebu	1       	Fri Apr 26 18:54:26 2019	DEPLOYED	testapi-chart-0.1.0	1.0        	default

修改Chart的打包版本0.1.0–>0.1.1，再次执行打包、发布，再次查看：

12345
 
kubectl get deployments

NAME                           READY   UP-TO-DATE   AVAILABLE   AGElumbering-zebu-testapi-chart   1/1     1            1           13modd-chicken-testapi-chart      1/1     1            1           85s

出现2个了，现在需要删除旧版本的deployment的chart：helm delete lumbering-zebu-testapi-chart，通过helm ls和kubectl get pods可以发现旧版本的deployment都已经被删除。删除后同样可以回滚：

123456
 
# 将testapi包按顺序回滚1次修改，注意不带-testapi-charthelm rollback lumbering-zebu 1# 输出Rollback was a success! Happy Helming!# 验证helm ls

但这种情况必须记得删除包的名字，实际可以通过helm ls --deleted查看已删除包的名字。

 升级，可以在修改相关的Chart.yaml文件后，直接在其所在目录运行helm upgrade odd-chicken .命令即可更新：

12345
 
# 验证helm ls# 版本号已变NAME       	REVISION	UPDATED                 	STATUS  	CHART               	APP VERSION	NAMESPACEodd-chicken	2       	Fri Apr 26 19:26:21 2019	DEPLOYED	testapi-chart2-2.1.1	2.0        	default

【设置Helm仓库】

 越来越觉得这东西像mvn了，Helm的仓库就是一个WEB服务器，如从charts目录提供helm服务：helm serve --repo-path ./charts。此外关于Chart服务的管理可能需要安装Monocular来提供WEB页面，安装步骤如下：

123456789101112
 
# 拉取所需要的镜像docker pull registry.cn-shanghai.aliyuncs.com/hhu/defaultbackend:1.4docker tag registry.cn-shanghai.aliyuncs.com/hhu/defaultbackend:1.4 k8s.gcr.io/defaultbackend:1.4docker rmi registry.cn-shanghai.aliyuncs.com/hhu/defaultbackend:1.4

# 安装Nginx Ingress controllerhelm install stable/nginx-ingress --set controller.hostNetwork=true,rbac.create=true

# 添加源（最新的源）helm repo add monocular https://helm.github.io/monocular# 安装monocularhelm install monocular/monocular

然后等待，安装完了之后，即可通过

【使用Helm仓库】

 使用Helmet作为Helm仓库，可以将它部署到K8S集群中并添加Chart。

转自：https://blog.wgl.wiki/K8S%E4%B8%AD%E9%83%A8%E7%BD%B2Helm/

原文地址：https://www.cnblogs.com/wangshuyang/p/12303524.html

时间： 2024-07-29 23:29:47

【转】K8S中部署Helm的相关文章

k8s中部署基于nfs的StorageClass

k8s中部署基于nfs的StorageClass ? storageclass相当于是一个动态的存储,即每个pod需要多少容量,直接在配置资源清单中声明即可;但是nfs默认是不支持storageclass动态存储的. ? 总结一下就是: ? 1. 平时使用过程中,如果是静态的存储,那么过程是先准备好存储,然后基于存储创建PV;然后在创建PVC,根据容量他们会找对应的PV ? 2. 使用动态存储,那么就是先准备好存储,然后直接创建PVC,storageclass会根据要求的大小自动创建PV 首先安

K8S（二）——K8S中部署tomcat集群

1.在k8s的搭建清楚的前提下,及所有的node均是ready状态的,方可进行一下步骤 2.查看是否有pod在运行,如果有,删除掉 kubectl get pod kubectl get deployment  3.需要准备jdk.tomcat.以及一个简单war包 JDK:链接:https://pan.baidu.com/s/1IOOsJEDTRpC3e7byOPydpA  提取码:b2c7 WAR:链接:https://pan.baidu.com/s/1cFrUldbTDmSxWYhIawx

k8s中helm安装部署，升级和回滚（chart，helm，tiller，StorageClass）

一.Helm介绍 helm是基于kubernetes 的包管理器.它之于 kubernetes 就如 yum 之于 centos,pip 之于 python,npm 之于 javascript 那 helm 的引入对于管理集群有哪些帮助呢? 更方便地部署基础设施,如 gitlab,postgres,prometheus,grafana 等 更方便地部署自己的应用,为公司内部的项目配置 Chart,使用 helm 结合 CI,在 k8s 中部署应用一行命令般简单 1.Helm用途 Helm把Kub

k8s中helm的使用

什么是 Helm在没使用 helm 之前,向 kubernetes 部署应用,我们要依次部署 deployment.svc 等,步骤较繁琐.况且随着很多项目微服务化,复杂的应用在容器中部署以及管理显得较为复杂,helm 通过打包的方式,支持发布的版本管理和控制,很大程度上简化了 Kubernetes 应用的部署和管理Helm 本质就是让 K8s 的应用管理(Deployment,Service 等 ) 可配置,能动态生成.通过动态生成 K8s 资源清单文件(deployment.yaml,ser

K8S集群中使用Helm管理应用分发

本文介绍在k8s上部署和使用helm.Helm是Kubernetes的一个包管理工具,用来简化Kubernetes应用的部署和管理.可以把Helm比作CentOS的yum工具. 通过使用使用Helm可以管理Kubernetes manifest files.管理Helm安装包charts.基于chart的Kubernetes应用分发. 一.Helm的基本概念 Chart: 是helm的应用打包格式.Chart由一系列文件组成,这些文件类似rpm包 Chart目录结构:1.chart.yamlYa

Helm, 在Kubernetes中部署应用的利器

一.背景 Kubernetes(k8s)是一个基于容器技术的分布式架构领先方案.它在Docker技术的基础上,为容器化的应用提供部署运行.资源调度.服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性.在容器云环境及容器化服务在业界开始大规模部署应用的前提下,Kubernetes在业界的实际应用情况又是怎样的呢?在今年召开的JFrog SwampUp用户大会上,Codefresh公司为大家展示了一些有意思的数据.如下图: 据Codefresh公司统计,在目前JFrog的企业用户当

k8s中Helm安装使用（15）

概念:helm把一系列复杂的有状态和无状态服务的部署封装起来(实际上就是对yaml文件的组织),然后你可以暴露出一些自定义参数信息供用户选择,这样部署就会变得简单很多.有点类似ansible,salt的yaml文件差不多.Helm相当于kubernetes环境下的yum包管理工具 组件:Helm :是一个命令行下的客户端工具 Tiller: 是 Helm 的服务端,部署在 Kubernetes 集群中 Chart Helm :的软件包,类似YUM 的 RPM 包 Repoistory Helm

国内不fq安装K8S三: 使用helm安装kubernet-dashboard

目录 3 使用helm安装kubernet-dashboard 3.1 Helm的安装 3.2 使用Helm部署Nginx Ingress 3.3 使用Helm部署dashboard 3.4 使用Helm部署metrics-server 国内不fq安装K8S一: 安装docker 国内不fq安装K8S二: 安装kubernet 国内不fq安装K8S三: 使用helm安装kubernet-dashboard 国内不fq安装K8S四: 安装过程中遇到的问题和解决方法 本文是按照"青蛙小白"

Spark on K8S环境部署细节

Spark on K8S环境部署细节 sparkk8s time: 2020-1-3 Spark on K8S环境部署细节 Spark operator安装 准备kubectl客户端和Helm客户端 安装spark operator Spark wordcount 读写OSS 准备oss依赖的jar包 准备core-site.xml 打包支持读写oss的镜像 下载spark安装包解压 打包发布镜像 准备wordcount作业 1. spark submit 提交 2. spark operato