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 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.
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.
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.
Non-Workload resource types, such as Secret, ServiceAccount, Role, etc., are categorically identified and loaded into the
k8s Resourcespage 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.
|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.
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 divides the applications based on the
label defined by the resource, e.g. resources matching
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.
Once the import is complete, the
wp-mysql applications are ready to be managed using Rainbond.
wordpressrelied on a
NodePortto 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
wordpressservice component once for the access policy to take effect.
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.
My deployment of this
wordpresssystem uses the
hostpathmodel for storage of all components, which is a simple configuration but not suitable for large-scale Kubernetes environments where
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.
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.