计算巢使用helm hook实现helm chart在ack集群中部署

本文涉及的产品
资源编排,不限时长
简介: 计算巢是阿里云开放给ISV与其客户的服务管理PaaS平台,旨在解决ISV云上交付、部署、运维问题,建立ISV与客户之间的通道。针对ISV的实际场景,计算巢提供了私有化部署、托管版部署、代运维服务三种模式。托管版和私有化部署的区别是针对于部署在ISV的账号下还是部署在用户账号下。本文主要介绍如何在计算巢中,通过服务部署helm chart到ack集群中。

计算巢简介

计算巢是阿里云开放给ISV与其客户的服务管理PaaS平台,旨在解决ISV云上交付、部署、运维问题,建立ISV与客户之间的通道。针对ISV的实际场景,计算巢提供了私有化部署、托管版部署、代运维服务三种模式。托管版和私有化部署的区别是针对于部署在ISV的账号下还是部署在用户账号下。

本文主要介绍如何在计算巢中,通过服务部署helm chart到ack集群中。

实现思路

利用ROS进行服务部署

计算巢服务部署主要借助于[ROS资源编排服务](https://www.aliyun.com/product/ros)来实现资源编排, 因此最初的实现思路是使用ros的ClusterHelmApplication直接进行部署,对应的模版关键部分如下:

ClusterHelmApplication:
    Type: ALIYUN::CS::ClusterHelmApplication
    DependsOn:
      - AddonsSleep
    Properties:
      ChartValues:
        Ref: ChartValues
      ClusterId:
        Fn::If:
          - CreateAck
          - Fn::GetAtt:
              - ManagedKubernetesCluster
              - ClusterId
          - Ref: ClusterId
      ChartUrl:
        Ref: ChartUrl
      Namespace:
        Ref: Namespace
      Name:
        Ref: Name

经过测试发现,这种方式存在两个问题:

  1. 存放在acr镜像仓库中的helm chart包不支持转成https链接使用
  2. ack线上部署依赖的helm版本为3.0.7,不支持helm一些比较高级的语法。如部署nginx服务时,提示不支持lookup函数。

job中helm命令安装

既然使用ack提供的线上部署方式走不通,就考虑直接使用helm命令进行安装,实现方式就是在ack集群中起个job,在job中进行helm chart部署的动作,模版关键部分如下:

Resources:
  ClusterUserKubeconfig:
    Type: DATASOURCE::CS::ClusterUserKubeconfig
    Properties:
      ClusterId:
        Ref: ClusterId
  ClusterApplication:
    Type: ALIYUN::CS::ClusterApplication
    Properties:
      YamlContent: 
        Fn::Sub:
          - |
            apiVersion: batch/v1
            kind: Job
            metadata:
              name: helm-install-job
            spec:
              template:
                metadata:
                  name: helm-install-job
                spec:
                  containers:
                  - name: helm-intall
                    image: alpine/helm:3.12.0
                    command: [ "/bin/sh", "-c", "--" ] 
                    args: ["cd ~; mkdir ~/.kube; echo '${KubeConfig}' | base64 -d >> ~/.kube/config; chartPackage=$({{ computenest::helmpull::test }}); helm install $chartPackage --generate-name;"]
                  restartPolicy: Never
          - KubeConfig:
              Fn::Base64Encode:
                Fn::GetAtt:
                  - ClusterUserKubeconfig
                  - Config

在job中将KubeConfig写到config文件中,然后执行helm pull命令,最后使用helm install命令进行helm chart安装,其中的{{ computenest::helmpull::test }}标识符会被替换为helm chart下载命令。

这种方式的问题是job进行了helm chart的部署,服务实例进行删除时,helm chart并不会进行卸载。

Helm Hook方式进行安装

helm提供了hook功能,可以在post-install-hook中进行helm chart的安装操作,在pre-delete-hook中进行helm chart的卸载操作,这样就可以解决job只进行了部署,未进行卸载的问题了。

同样还是使用ros的ClusterHelmApplication资源类型,去运行helm hook模版框架,在框架中去执行helm chart的安装和卸载。

post-install-hook处理逻辑如下:

apiVersion: batch/v1
kind: Job
metadata:
  name: post-install-job-{{ .Release.Name }}
  labels:
    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
    app.kubernetes.io/instance: {{ .Release.Name | quote }}
    app.kubernetes.io/version: {{ .Chart.AppVersion }}
    helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
  annotations:
    # This is what defines this resource as a hook. Without this line, the
    # job is considered part of the release.
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    metadata:
      name: "{{ .Release.Name }}"
      labels:
        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
        app.kubernetes.io/instance: {{ .Release.Name | quote }}
        helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    spec:
      restartPolicy: Never
      containers:
        - name: post-install-job
          image: "alpine/helm:3.12.0"
          command:  [ "/bin/sh", "-c", "--" ]
          args: ["
              set -x;
              cd ~;
              curl -LO \"https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl\"; 
              install -o root -g root -m 0755 kubectl /usr/bin/kubectl;
              mkdir ~/.kube; echo {{ .Values.Kubeconfig }} | base64 -d >> ~/.kube/config;
              echo {{ toYaml .Values.ChartValues | b64enc }} | base64 -d > values.yaml;  
              export HELM_EXPERIMENTAL_OCI=1; 
              wget {{ .Values.ChartUrl }};
              data=$(helm install {{.Values.ReleaseName}} {{ .Values.ChartPackage }} -f values.yaml --namespace {{ .Values.ChartNamespace }} | base64 | tr -d '\n');
              if [ -n \"{{ .Values.OutputCmd | b64enc }}\" ];
              then
                  sleep {{ .Values.InstallSeconds }};
                  echo {{ .Values.OutputCmd | b64enc }} | base64 -d > outputCmd.sh; 
                  data=$(source outputCmd.sh | base64 | tr -d '\n');
              fi;
              {{ .Values.CurlCli }} -d \"{\\\"Data\\\":\\\"$data\\\",\\\"status\\\":\\\"SUCCESS\\\"}\";
              "]

pre-delete-hook的处理逻辑如下:

apiVersion: batch/v1
kind: Job
metadata:
  name: pre-delete-job-{{ .Release.Name }}
  labels:
    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
    app.kubernetes.io/instance: {{ .Release.Name | quote }}
    app.kubernetes.io/version: {{ .Chart.AppVersion }}
    helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
  annotations:
    # This is what defines this resource as a hook. Without this line, the
    # job is considered part of the release.
    "helm.sh/hook": pre-delete
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    metadata:
      name: "{{ .Release.Name }}"
      labels:
        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
        app.kubernetes.io/instance: {{ .Release.Name | quote }}
        helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    spec:
      restartPolicy: Never
      containers:
      - name: pre-delete-job
        image: "alpine/helm:3.12.0"
        command:  [ "/bin/sh", "-c", "--" ] 
        args: ["
            cd ~; 
            mkdir ~/.kube; 
            echo {{ .Values.Kubeconfig }} | base64 -d >> ~/.kube/config; 
            export HELM_EXPERIMENTAL_OCI=1; 
            helm uninstall {{ .Values.ReleaseName }} --namespace {{ .Values.ChartNamespace }};
        "]

计算巢服务模版关键部分如下,将真正要部署的chartUrl通过values的方式传到helm hook部署模版中:

总结

在计算巢中在线部署helm chart到ack集群的探索过程中,遇到了很多的问题,现有的云产品对通过api调用和在线使用支持不是很完善,估计是这种使用方式比较少,大部分用户还是通过命令来执行,比如acr服务不支持https方式拉取,ack的ack-helm-manager对应的helm版本过低,最终只能想办法通过其它路径来达到想要的效果。

 

相关实践学习
2048小游戏
基于计算巢&ECS云服务器快速部署,带您畅玩2048小游戏。
相关文章
|
2天前
|
存储 Kubernetes 容器
K8S部署nexus
该配置文件定义了Nexus 3的Kubernetes部署,包括PersistentVolumeClaim、Deployment和服务。PVC请求20Gi存储,使用NFS存储类。Deployment配置了一个Nexus 3容器,内存限制为6G,CPU为1000m,并挂载数据卷。Service类型为NodePort,通过30520端口对外提供服务。所有资源位于`nexus`命名空间中。
|
11天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
|
2月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
135 60
|
25天前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
1月前
|
Kubernetes 监控 Cloud Native
Kubernetes集群的高可用性与伸缩性实践
Kubernetes集群的高可用性与伸缩性实践
71 1
|
2月前
|
JSON Kubernetes 容灾
ACK One应用分发上线:高效管理多集群应用
ACK One应用分发上线,主要介绍了新能力的使用场景
|
1月前
|
存储 Kubernetes Devops
Kubernetes集群管理和服务部署实战
Kubernetes集群管理和服务部署实战
49 0
|
2月前
|
Kubernetes 持续交付 开发工具
ACK One GitOps:ApplicationSet UI简化多集群GitOps应用管理
ACK One GitOps新发布了多集群应用控制台,支持管理Argo CD ApplicationSet,提升大规模应用和集群的多集群GitOps应用分发管理体验。
|
2月前
|
Kubernetes Ubuntu Linux
Centos7 搭建 kubernetes集群
本文介绍了如何搭建一个三节点的Kubernetes集群,包括一个主节点和两个工作节点。各节点运行CentOS 7系统,最低配置为2核CPU、2GB内存和15GB硬盘。详细步骤包括环境配置、安装Docker、关闭防火墙和SELinux、禁用交换分区、安装kubeadm、kubelet、kubectl,以及初始化Kubernetes集群和安装网络插件Calico或Flannel。
203 4
|
2月前
|
NoSQL 关系型数据库 Redis
高可用和性能:基于ACK部署Dify的最佳实践
本文介绍了基于阿里云容器服务ACK,部署高可用、可伸缩且具备高SLA的生产可用的Dify服务的详细解决方案。

热门文章

最新文章

下一篇
DataWorks