计算巢使用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小游戏。
相关文章
|
6天前
|
存储 Kubernetes 对象存储
部署DeepSeek但GPU不足,ACK One注册集群助力解决IDC GPU资源不足
借助阿里云ACK One注册集群,充分利用阿里云强大ACS GPU算力,实现DeepSeek推理模型高效部署。
|
11天前
|
存储 Kubernetes 测试技术
企业级LLM推理部署新范式:基于ACK的DeepSeek蒸馏模型生产环境落地指南
本教程演示如何在ACK中使用vLLM框架快速部署DeepSeek R1模型推理服务。
|
12天前
|
存储 人工智能 弹性计算
NVIDIA NIM on ACK:优化生成式AI模型的部署与管理
本文结合NVIDIA NIM和阿里云容器服务,提出了基于ACK的完整服务化管理方案,用于优化生成式AI模型的部署和管理。
|
1天前
|
Kubernetes 持续交付 数据库
阿里云ACK+GitLab企业级部署实战教程
GitLab 是一个功能强大的基于 Web 的 DevOps 生命周期平台,整合了源代码管理、持续集成/持续部署(CI/CD)、项目管理等多种工具。其一体化设计使得开发团队能够在同一平台上进行代码协作、自动化构建与部署及全面的项目监控,极大提升了开发效率和项目透明度。 GitLab 的优势在于其作为一体化平台减少了工具切换,高度可定制以满足不同项目需求,并拥有活跃的开源社区和企业级功能,如高级权限管理和专业的技术支持。借助这些优势,GitLab 成为许多开发团队首选的 DevOps 工具,实现从代码编写到生产部署的全流程自动化和优化。
|
6天前
|
人工智能 Kubernetes 异构计算
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
本教程演示如何在ACK中多机分布式部署DeepSeek R1满血版。
|
1月前
|
缓存 容灾 网络协议
ACK One多集群网关:实现高效容灾方案
ACK One多集群网关可以帮助您快速构建同城跨AZ多活容灾系统、混合云同城跨AZ多活容灾系统,以及异地容灾系统。
|
2月前
|
Kubernetes Ubuntu 网络安全
ubuntu使用kubeadm搭建k8s集群
通过以上步骤,您可以在 Ubuntu 系统上使用 kubeadm 成功搭建一个 Kubernetes 集群。本文详细介绍了从环境准备、安装 Kubernetes 组件、初始化集群到管理和使用集群的完整过程,希望对您有所帮助。在实际应用中,您可以根据具体需求调整配置,进一步优化集群性能和安全性。
152 12
|
2月前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
2月前
|
存储 Kubernetes 容器
K8S部署nexus
该配置文件定义了Nexus 3的Kubernetes部署,包括PersistentVolumeClaim、Deployment和服务。PVC请求20Gi存储,使用NFS存储类。Deployment配置了一个Nexus 3容器,内存限制为6G,CPU为1000m,并挂载数据卷。Service类型为NodePort,通过30520端口对外提供服务。所有资源位于`nexus`命名空间中。
|
2月前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes Ingress:灵活的集群外部网络访问的利器
《Kubernetes Ingress:集群外部访问的利器-打造灵活的集群网络》介绍了如何通过Ingress实现Kubernetes集群的外部访问。前提条件是已拥有Kubernetes集群并安装了kubectl工具。文章详细讲解了Ingress的基本组成(Ingress Controller和资源对象),选择合适的版本,以及具体的安装步骤,如下载配置文件、部署Nginx Ingress Controller等。此外,还提供了常见问题的解决方案,例如镜像下载失败的应对措施。最后,通过部署示例应用展示了Ingress的实际使用方法。
87 2

热门文章

最新文章