You are viewing documentation for KubeSphere version:v3.0.0

KubeSphere v3.0.0 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.

DevOps — Overview

DevOps is a set of practices and tools that automate the processes between IT and software development teams. Among other things, as agile software development sees increasing popularity, continuous integration (CI) and continuous delivery (CD) have become an ideal solution in this connection. In a CI/CD workflow, every integration is tested through automatic building, including coding, releasing and testing. This helps developers to identify any integration errors beforehand and teams can deliver internal software to a production environment with speed, security, and reliability.

Nevertheless, the traditional master-agent architecture of Jenkins (i.e. multiple agents work for a master) has the following shortcomings.

  • The entire CI/CD pipeline will crash once the master goes down.
  • Resources are not allocated equally as some agents see pipeline jobs wait in queue while others remain idle.
  • Different agents may be configured in different environments and require different coding languages. The disparity can cause inconvenience in management and maintenance.

Understand KubeSphere DevOps

KubeSphere DevOps projects support source code management tools such as GitHub, Git, and SVN. Users can build CI/CD pipelines through graphical editing panels (Jenkinsfile out of SCM) or create a Jenkinsfile-based pipeline from the code repository (Jenkinsfile in SCM).

Features

The KubeSphere DevOps system provides you with the following features:

pipeline-list

sonarqube-result-detail

KubeSphere CI/CD pipeline workflows

A KubeSphere CI/CD pipeline runs on the back of the underlying Kubernetes Jenkins agents. These Jenkins agents can be dynamically scaled as they are dynamically provisioned or released based on the job status. The Jenkins master and agents run as Pods on KubeSphere nodes. The master runs on one of the nodes with its configuration data stored in a volume. Agents run across nodes while they may not be active all the time because they are created dynamically and deleted automatically as needed.

When the Jenkins master receives a building request, it dynamically creates Jenkins agents that run in Pods according to labels. At the same time, Jenkins agents will be registered in the master. After agents finish their jobs, they will be released and related Pods will be deleted as well.

Dynamically provision Jenkins agents

The advantages of dynamically provisioning Jenkins agents are:

Reasonable resource allocation. KubeSphere dynamically assigns agents created to idle nodes, so that jobs will not be queuing on a single node whose resource utilization is already high.

High scalability. When a KubeSphere cluster has insufficient resources which lead to long waiting time of jobs in the queue, you can add new nodes to the cluster.

High availability. When a Jenkins master fails, KubeSphere automatically creates a new Jenkins master container with the volume mounted to the new container. In this way, the data are secured with high availability achieved for the cluster.