Skip to main content

· 阅读需要 1 分钟

You may have learned from this blog that we can use vela to manage cloud resources (like s3 bucket, AWS EIP and so on) via the terraform plugin. We can create an application which contains some cloud resource components and this application will generate these cloud resources, then we can use vela to manage them.

Sometimes we already have some Terraform cloud resources which may be created and managed by the Terraform binary or something else. In order to have the benefits of using KubeVela to manage the cloud resources or just maintain consistency in the way you manage cloud resources, we may want to import these existing Terraform cloud resources into KubeVela and use vela to manage them. But if we just create an application which describes these cloud resources, the cloud resources will be recreated and may lead to errors. To fix this problem, we made a simple backup_restore tool. This blog will show you how to use the backup_restore tool to import your existing Terraform cloud resources into KubeVela.

Step 1: Create Terraform Cloud Resources

Since we are going to demonstrate how to import an existing cloud resource into KubeVela, we need to create one first. If you already have such resources, you can skip this step.

Before start, make sure you have:

Let's get started!

  1. Create an empty directory to start.

    mkdir -p cloud-resources
    cd cloud-resources
  2. Create a file named main.tf which will create a S3 bucket:

    resource "aws_s3_bucket" "bucket-acl" {
    bucket = var.bucket
    acl = var.acl
    }

    output "RESOURCE_IDENTIFIER" {
    description = "The identifier of the resource"
    value = aws_s3_bucket.bucket-acl.bucket_domain_name
    }

    output "BUCKET_NAME" {
    value = aws_s3_bucket.bucket-acl.bucket_domain_name
    description = "The name of the S3 bucket"
    }

    variable "bucket" {
    description = "S3 bucket name"
    default = "vela-website"
    type = string
    }

    variable "acl" {
    description = "S3 bucket ACL"
    default = "private"
    type = string
    }
  3. Configure the AWS Cloud provider credentials:

    export AWS_ACCESS_KEY_ID="your-accesskey-id"
    export AWS_SECRET_ACCESS_KEY="your-accesskey-secret"
    export AWS_DEFAULT_REGION="your-region-id"
  4. Set the variables in the main.tf file:

    export TF_VAR_acl="private"; export TF_VAR_bucket="your-bucket-name"
  5. (Optional) Create a backend.tf to configure your Terraform backend. We just use the default local backend in this example.

  6. Run terraform init and terraform apply to create the S3 bucket:

    terraform init && terraform apply
  7. Check the S3 bucket list to make sure the bucket is created successfully.

  8. Run terraform state pull to get the Terraform state of the cloud resource and store it into a local file:

    terraform state pull > state.json

Step 2: Import Existing Terraform Cloud Resources into KubeVela

  1. Create the application.yaml file, please ensure that the description of each field of Component is consistent with your cloud resource configuration:

    apiVersion: core.oam.dev/v1beta1
    kind: Application
    metadata:
    name: app-aws-s3
    spec:
    components:
    - name: sample-s3
    type: aws-s3
    properties:
    bucket: vela-website-202110191745
    acl: private
    writeConnectionSecretToRef:
    name: s3-conn
  2. Get the backup_restore tool:

    git clone https://github.com/kubevela/terraform-controller.git
    cd terraform-controller/hack/tool/backup_restore
  3. Run the restore command:

    go run main.go restore --application <path/to/your/application.yaml> --component sample-s3 --state <path/to/your/state.json>

    The above command will resume the Terraform backend in the Kubernetes first and then create the application without recreating the S3 bucket.

That's all! You have successfully migrate the management of the S3 bucket to KubeVela!

What's more

For more information about the backup_restore tool, please read the doc. If you have any problem, issues and pull requests are always welcome.

· 阅读需要 1 分钟

Helm Charts 如今已是一种非常流行的软件打包方式,在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中,业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下,单纯依赖 Helm 工具可能无法做到灵活的部署和交付。

在本文中,我们将介绍如何通过 KubeVela 解决多集群环境下 Helm Chart 的部署问题。如果你手里没有多集群也不要紧,我们将介绍一种仅依赖于 Docker 或者 Linux 系统的轻量级部署方式,可以让你轻松的体验多集群功能。当然,KubeVela 也完全具备单集群的 Helm Chart 交付能力。

· 阅读需要 1 分钟

如果您正在寻找将 Terraform 生态系统与 Kubernetes 世界粘合在一起的东西,那么恭喜!你在这个博客中得到了你想要的答案。

随着各大云厂商产品版图的扩大,基础计算设施,中间件服务,大数据/AI 服务,应用运维管理服务等都可以直接被企业和开发者拿来即用。我们注意到也有不少企业基于不同云厂商的服务作为基础来建设自己的企业基础设施中台。为了更高效,统一的管理云服务,IaC 思想近年来盛行,其中 Terrafrom 更是成功得到了几乎所有的云厂商的采纳和支持。以 Terrafrom 模型为核心的云服务 IaC 生态已经形成。然而在 Kubernetes 大行其道的今天,IaC 被冠以更广大的想象空间,Terraform IaC 能力和生态成果如果融入 Kubernetes 世界,我们认为这是一种强强联合。

· 阅读需要 1 分钟
孙健波,曾庆国

KubeVela 是一个现代化的软件交付控制平面,目标是让应用的部署和运维在如今的混合多云环境下更简单、敏捷、可靠。自 1.1 版本发布以来,KubeVela 架构上天然打通了企业面向混合多云环境的交付难题,且围绕 OAM 模型提供了充分的可扩展性,赢得了大量企业开发者的喜爱,这也使得 KubeVela 的迭代速度不断加快。

1.2 版本我们发布了开箱即用的可视化控制台,终端用户可以通过界面发布和管理多样化的工作负载;1.3 版本 的发布则完善了以 OAM 模型为核心的扩展体系,提供了丰富的插件功能,并给用户提供了包括 LDAP 权限认证在内的大量企业级功能,同时为企业集成提供了巨大的便利。至今为止,你已经可以在 KubeVela 社区的插件中心里获得 30 多种插件,其中不仅包含了 argocd、istio、traefik 这样的 CNCF 知名项目,更有 flink、mysql 等数据库中间件,以及上百种不同云厂商资源可供直接使用。

在这次发布的 1.4 版本中,我们围绕让应用交付更安全、上手更简单、过程更透明三个核心,加入了包括多集群权限认证和授权、复杂资源拓扑展示、一键安装控制平面等核心功能,全面加固了多租户场景下的交付安全性,提升了应用开发和交付的一致性体验,也让应用交付过程更加透明化。

· 阅读需要 1 分钟

在应用交付中另一个很大的诉求是对资源交付流程的透明化管理,比如社区里很多用户喜欢使用 Helm Chart ,把一大堆复杂的 YAML 打包在一起,但是一旦部署出现问题,如底层存储未正常提供、关联资源未正常创建、底层配置不正确等,即使是一个很小的问题也会因为整体黑盒化而难以排查。尤其是在现代混合的多集群混合环境下,资源类型众多、错综复杂,如何从中获取到有效信息并解决问题是一个非常大的难题。

· 阅读需要 1 分钟
Jianbo Sun

This blog will introduce how to use CUE and KubeVela to build you own abstraction API to reduce the complexity of Kubernetes resources. As a platform builder, you can dynamically customzie the abstraction, build a path from shallow to deep for your developers per needs, adapt to growing number of different scenarios, and meet the iterative demands of the company's long-term business development.

· 阅读需要 1 分钟
KubeVela 社区

得益于 KubeVela 社区上百位开发者的参与和 30 多位核心贡献者的 500 多次代码提交, KubeVela 1.3 版本正式发布。相较于三个月前发布的 v1.2 版本,新版本在 OAM 核心引擎(Vela Core),可视化应用交付平台 (VelaUX) 和社区插件生态这三方面都给出了大量新特性。这些特性的诞生均源自于阿里巴巴、LINE、招商银行、爱奇艺等社区用户大量的深度实践,最终贡献到 KubeVela 项目中,形成大家可以开箱即用的功能。

· 阅读需要 1 分钟
段威(段少)

在当今的多集群业务场景下,我们经常遇到的需求有:分发到多个指定集群、按业务规划实现分组分发、以及对多集群进行差异化配置等等。

KubeVela v1.3 在之前的多集群功能上进行了迭代,本文将为你揭示,如何使用 KubeVela 进行多集群应用的部署与管理,实现以上的业务需求。

· 阅读需要 1 分钟
马祥博

招商银行云平台开发团队自2021年开始接触 KubeVela,并探索 KubeVela 在招商银行云平台的落地实践,借此提升云原生应用交付与管理能力。同时因为金融保险行业的特殊性,网络安全管控措施相对严格,行内网络无法直接拉取 Docker Hub 镜像,同时行内暂时没有可用的 Helm 镜像源。因此,要想实现 KubeVela 在行内私有环境的落地,必须进行完全的离线部署。

本文将以 KubeVela v1.2.5 版本为例,介绍招商银行 KubeVela 的离线部署实践,来帮助其他用户在离线环境中更便捷的完成 KubeVela 的部署。

· 阅读需要 1 分钟
Tianxin Dong and Yicai Yu

在云原生快速发展的当下,如何让云的技术赋能业务开发?在上线应用时,如何让云的开发者在现代化的多集群、混合云环境中便捷地进行应用的开发和调试?在部署过程中,又该如何让应用部署具备充分的验证和可靠性?

这些至关重要的问题,都是我们急需解决的。

在本文中,我们将结合 KubeVela 以及 Nocalhost 开源项目,给出一个基于 Kubernetes 和容器生态的端云联调、一键完成多集群混合环境部署的解决方案,来回答上述问题。