Kubernetes abstracts everything within its own boundaries as resources. The main part of this is the workload workload controller, represented by Deployment and StatefulSet, and all other resources work around these main resources. Combined, these resources present a workload-centric model for IT technologists.

All resources in Kubernetes are described in declarative configuration files, which are defined by Yaml fields, giving IT technicians the greatest freedom while also placing high demands on their skills.

Simplify Kubernetes Management with Application Models

When your team has been using native Kubernetes for a while, you will most likely find that not every IT technician is good at writing complex Kubernetes declarative configuration files (YAML). Especially for developers whose primary responsibility is business development, learning and writing YAML can be burdensome and even resistant to use.

The open source project Rainbond is a cloud-native application management platform that uses the application-centric design pattern. Based on this design pattern, it re-abstracts a higher level application model than workload. From the experience of using it, there is no need to learn and write YAML to achieve the full lifecycle management of business applications. The application corresponds to a complete business system and consists of several service components that can be managed separately. Each service component can be defined based on a graphical interface using some common operation and maintenance features. On top of that, users can use the core concept of application model to make more advanced operations, such as publishing the whole business system as an application template, and the business system can be installed/upgraded based on the template with one click. This capability is very useful in this area of software delivery, where rapid delivery and even personalized delivery can be made based on the application template, regardless of whether the final delivery environment is online or offline.

Rainbond

Rainbond uses an application model that allows developers to focus on the application and the business itself, making it easier to be accepted. The preserved O&M features are presented and interacted with through a graphical interface, which greatly reduces the ease of use. Most developers can use Kubernetes without having to edit complex declarative configuration files through the application templates.

Converting Kubernetes YAML into an application model

The whole process of conversion can be summarized in three steps.

  1. For the most common Workloads used by developers, they can be automatically generated from source and container images wizard-style, or imported into existing YAML and run applications. The import process automatically identifies all transformable Workload type resources, including Deployment, StatefulSet, Job, and CronJob types. These resources will be transformed into the application model and run as a service component after the transformation.

  2. After importing the generated service components, the basic Workload properties can be viewed and edited through the interface, such as environment variables, mirror addresses, etc. The advanced Workload properties identified during the conversion process will be added to the service component, which can be viewed and managed in the form of Key/Value or Yaml. 3.

  3. Non-Workload resource types, such as Secret, ServiceAccount, Role, etc., are categorically identified and loaded into the k8s Resources page of the application interface for the operator to edit in an interactive experience.

Advanced Workload properties that can be managed and transformed include the following.

property name role
nodeSelector used when specifying a certain type of node scheduling.
labels Used to customize the label for the service component to be used by the selector.
volumes Used to define mounts for volume types that are not managed by Rainbond.
volumeMounts Use with volumes to mount volumes to containers.
affinity More advanced scheduling methods, including Node Affinity and Pod Affinity.
tolerations Used with node taint, Pods with the specified tolerance can only be scheduled to the specified node.
serviceAccountName Assign an existing SA to a service component to give the corresponding Pod certain privileges.
privileged A veritable configuration, not necessary not to open.
env Used to define environment variables that are not managed by Rainbond and support reference operations.

It is worth noting that the extended RAM model can still be published as an application template for subsequent one-click installation/upgrade/delivery of the entire business system.

Testing and practice of importing existing Kubernetes applications

The following tests are based on Rainbond v5.8. In order to test the import of existing Kubernetes applications, I plan to perform an import test using the Wordpress site building system that has been deployed in the wp namespace. This system consists of the following resources.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wp
NAME                         TYPE                                  DATA   AGE
secret/default-token-nq5rs   kubernetes.io/service-account-token   3      27m
secret/mysql-secret          Opaque                                2      27m
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/wordpress   NodePort    10.43.157.40    <none>        8080:30001/TCP   5m19s
service/wp-mysql    ClusterIP   10.43.132.223   <none>        3306/TCP         27m
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/wordpress   1/1     1            1           5m19s
NAME                        READY   AGE
statefulset.apps/wp-mysql   1/1     27m
NAME                             READY   STATUS    RESTARTS   AGE
pod/wordpress-66bc999449-qv97v   1/1     Running   0          5m19s
pod/wp-mysql-0                   1/1     Running   0          27m

Visit Rainbond and select Import at the cluster. On this page, you can select the namespace wp for the resource to be imported. The platform will group the resources according to the label.

Rainbond

Rainbond divides the applications based on the label defined by the resource, e.g. resources matching app.kubernetes.io/name:wp-mysql or app:wordpress will be distributed to two different applications in the diagram, while resources that do not have the above label will be uniformly divided into an ungrouped application. The division of applications is very critical, because the advanced application of the application model is for an application as a whole, so it is important to plan carefully and add a reasonable label before importing.

During the import process, Rainbond leaves the different properties to be managed by the extended model, and most of the operations are now easy to use, while the other parts are managed by the Kubernetes properties page.

Rainbond

Once the import is complete, the wordpress and wp-mysql applications are ready to be managed using Rainbond.

  • Port management

    wordpress relied on a Service of type NodePort to be exposed externally before the import, but after importing Rainbond management, it can expose its own port 80 to the public using a gateway. Note that you must restart the wordpress service component once for the access policy to take effect.

    Port management

    For some services, the access portal is not dynamically specified, which requires some changes on the business side to accommodate the new access portal as well. In the case of Wordpress, the site address in the general options needs to be redefined.

    Port management

  • Storage Management

    My deployment of this wordpress system uses the hostpath model for storage of all components, which is a simple configuration but not suitable for large-scale Kubernetes environments where Pods can drift.

    Rainbond, when deployed, provides easy-to-use shared storage that supports sharing data between multiple Pods and migration of Pods across hosts. The original hostpath storage can be redefined. The redefined storage path will become empty, so remember to find the old and new paths and perform a data migration.

    Storage Management

Practical Implications

The application model allows IT technicians to care more about the business itself rather than the underlying complexities of using the tools. The end effect is to simplify operational costs and understanding, making it easier to get Kubernetes off the ground.