takeaway: In recent years, more and more dedicated to Kubernetes to do application publishing tools began to appear, to help you manage and publish the increasing number of Kubernetes applications. When making the technology selection, we need to choose the best tool and the most stable base for the business. So how do you compare and measure these tools? In this article, Alibaba Cloud technical expert Deng Hongchao will share his unique experience with you to help readers get a preliminary understanding of Tekton project.

background

In recent years, with the rapid development of cloud native Community (CNCF Community), more and more applications run on K8s. Gradually, the focus has shifted from the resource layer to the application layer. On the one hand, we see more and more new K8s Operators appearing to automate application deployment and operation. On the other hand, with the arrival of large cloud vendors, the K8s service will be as freely available as water and electricity in your home, and there will be no point in building it yourself. So people say “K8s will disappear”, which actually means that using THE K8s as a base to deliver applications to any cloud or data center in the world will be the next inevitable trend. About this trend, students in our team have written a special article about K8s multi-cluster/multi-cloud Technology and Development, welcome you to read it further.

Related links:

  • According to Kubernetes will disappear: levelup.gitconnected.com/why-kuberne…
  • Kubernetes Multi-cluster Architecture in cloud Native era: www.infoq.cn/article/sbw…

What is special about the Tekton project?

Based on K8S to make application publishing tools, we have many choices, including Jenkins X and Spinnaker, which are well-known projects in the industry, as well as small tools from startups such as Argo Rollout. However, our team is mainly using Tekton. There is also an important background here, that is, the complex stateful Alibaba middleware application that our team is delivering for multi-cloud/multi-cluster. And I’ll talk about that in a minute.

For those of you who don’t know what the Tekton project is, right? So let me give you a quick introduction. Tekton is a k8S native application publishing framework, mainly used to build CI/CD systems. It was originally a subproject of the Knative project called build-Pipeline, which was used as the next generation engine of Knative build. However, as the diverse needs of the K8S community came in, the subproject grew into a general framework that provided a flexible and powerful ability to do build releases based on K8S.

Many students may wonder why we chose the Cinderella-like Tekton when there are so many multi-functional and prestigious projects. Don’t worry, let us first sort out the requirements of the platform base:

  1. K8s native: Processes and concepts, especially user-oriented ones, need to be integrated into the K8s architecture. In addition, it is better to be connected to other tools in the ecology and become part of the ecology.
  • For example, Spinnaker is a powerful project, but it was designed for public cloud application delivery (running on virtual machines). Kubernetes is just one Provider it supports, and providers use Groovy to write integration plug-ins. This makes it awkward to work with the K8s.
  • Flexible scaling: Almost all tools are inadequate to meet our complex and changing business needs. These tool architectures themselves need to be flexible enough to be extensible to quickly customize the required functionality.
    • For example, the application release of Argo Rollout itself is coupled to K8s Workload (such as Deployment). This is not a very scalable approach. The simplest example: for complex stateful applications, most of which are managed by Operator or OpenKruise, what should Argo Rollout do?


    • Lightweight: The tool itself cannot be “too heavy,” meaning it cannot have too many components or too many concepts. Small and light projects are easy to pick up at the beginning, easy to deliver at the middle, and easy to maintain at the end.
      • For example, Spinnaker is powerful, but that means it does everything for you. The application that our team will publish is a complex stateful middleware application, which requires us to write our own Rollout Controller to control the release process. This would require a lot of secondary development based on Spinnaker, and so many features and components would be a burden.
    1. White box: Pipelines and steps in operation need to be “white box”, that is, exposed to the outside. In this way, the front-end tool can be connected to display real-time status information to the user.
    • For example: Tekton only provides pipelines, which are directly mapped to K8s Pod and other API resources. For example, we write K8s Controller to realize the control of application publishing process, gray scale and online strategy, which is actually what we like. In addition, this design means that Tekton will not cover a “big hat” on K8s. For example, if we want to see the release status and log, we can directly check the status and log of the Pod corresponding to this Pipeline through K8s, without facing another API.

    Let’s make a comparison between several candidates:

    As you can see, Tekton has the advantage of flexible customization, K8s authenticity, and popularity in the community. This is why our team chose to build the application delivery system on Tekton when we were responsible for the delivery of complex stateful applications of Ali middleware.

    Practice case: Use Tekton automated application publishing

    Next we will share a practice case for publishing using Tekton Automation applications.

    The architecture of an application publishing platform based on Tekton is as follows:

    The process here is roughly as follows:

    1. Users write the applications to be deployed into YAML files (similar to Helm Chart) according to a set of standard application definitions.
    2. The user pushes the application definition YAML to the Git repository;
    3. < span style = “box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px; word-break: inherit! Important;”

    Tekton CD operations are classified into the following situations:

    • < span style = “box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px; font-size: 14px! Important; word-break: inherit! Important;”
    • < span style = “box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px! Important; word-break: inherit! Important;” Here we will do the upgrade according to the strategy in YAML application definition, such as canary publishing, gray scale upgrade.
    • < span style = “box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px! Important; word-break: inherit! Important;” After confirming that the application was deleted, we removed the application’s YAML from Git.

    Next, let’s look at a simple example of creating an application:

    In this example we generate a Tekton Pipeline. Run the pipeline to publish the application to the K8s cluster.

    Git is the boundary of user operations, and everything is automated thereafter. So how do users get feedback throughout the process? There are mainly:

    • Process state: Tekton Pipeline itself is the K8s API Object. We reveal the process state information to the front end by summarizing Status.
    • Logging and monitoring: Since Tekton Pipeline started with K8s pods, we could reuse the existing infrastructure to collect and do a summary.

    experience

    Here are the basics of the Tekton project and the main process of releasing apps using Tekton as a base. Sum up some experience here:

    1. Reuse open source technology. Less wheelbuilding means more focus on more valuable things;
    2. Don’t just focus on immediate requirements, focus on customization and extensibility, and think about future scenarios;
    3. The K8s application layer will accelerate next. It is an important trend in the future to help developers develop, deploy, and manage applications better on K8S and standardize related processes.

    In addition, Tekton 2019 development plan also includes conditional execution, cancelling or pausing a workflow, including a paused or failed workflow, enforcing timeouts on Tasks and Pipelines. Standing on the shoulders of giants, future app distribution platforms will be even more powerful.

    The original link

    This article is the original content of the cloud habitat community, shall not be reproduced without permission.