Kubernetes abstracts everything within its boundaries as resources. The main part is the workload workload controller represented by Deployment and StatefulSet, and other various resources work around these main resources. Combined, these resources can present a workload-centric model for IT technical workers. All resources in Kubernetes are edited and described through declarative configuration files, and the Yaml field definitions are defined one by one, which not only gives IT technicians the greatest degree of freedom, but also puts forward extremely high requirements on the ability of technicians.
Simplify Kubernetes management with application models
When your team has been using native Kubernetes for a while, you will probably find that not every IT technician is good at writing complex Kubernetes declarative configuration files (YAML). Especially for developers whose main responsibility is business development, learning and writing YAML can increase their burden and even resist using it.
The open source project Rainbond is a cloud-native application management platform that uses an application-centric design pattern. Based on this design pattern, a higher-level application model than workload is re-abstracted. There is no need to learn and write YAML from the experience of use, and realize the full life cycle management of business applications. The application corresponds to a complete business system, which consists of several service components that can be managed independently. When deploying business components, you can edit the service invocation relationship by "drag and drop" from source code and container images. Each service component can define and use some common operation and maintenance features based on the graphical interface. On this basis, users can also use the core concept of the application model to perform more advanced operations, such as publishing the entire business system in the form of an application template, and the business system can be installed/upgraded with one click based on the template. In the field of software delivery, this capability is very useful. Whether the final delivery environment is online or offline, it can be quickly delivered based on application templates, and even personalized delivery.
The application model used by Rainbond makes it easier for developers to focus on the application and business itself. The operation and maintenance features retained after cutting are displayed and interacted through a graphical interface, which greatly reduces the difficulty of use. Most developers can use Kubernetes smoothly without editing complex declarative configuration files through application templates.
Convert Kubernetes YAML to application model
The entire conversion process can be summarized in three steps:
- For the most commonly used Workloads by developers, they can be automatically generated from source code and container images in a wizard-like manner, or imported from existing YAML and run applications. The import process automatically identifies all convertible Workload type resources, including Deployment, StatefulSet, Job, and CronJob types. These resources will be transformed into application models, which will then run as service components.
- After importing the generated service components, basic Workload properties can be viewed and edited through the interface, such as environment variables, mirror addresses, and so on. During the conversion process, the identified advanced Workload properties will be added to the service components, which can be viewed and managed in the form of Key/Value or Yaml.
- Non-workload resource types, such as Secret, ServiceAccount, Role and other resources, will be classified, identified and loaded into the
k8s资源page for the operator to edit in an interactive experience.
Advanced Workload properties that can be managed and transformed include:
| property name | effect |
|---|---|
| nodeSelector | Node selector: used when specifying a certain type of node scheduling. |
| labels | Labels: Used to customize labels for service components to be used by selectors. |
| volumes | Storage Volumes: Mounts used to define types of volumes that are not managed by Rainbond. |
| volumeMounts | Mount volumes: Used in conjunction with volumes to mount volumes to containers. |
| affinity | Affinity: More advanced scheduling methods, including node affinity and pod affinity. |
| tolerations | Tolerance: Used in conjunction with node taint, Pods with specified tolerance can be scheduled to specified nodes. |
| serviceAccountName | Service account name: Specify an existing SA for the service component, so that the corresponding Pod has certain permissions. |
| privileged | Privileged mode: A veritable configuration, not turned on unless necessary. |
| env | Environment variables: used to define environment variables that are not managed by Rainbond, and support reference operations. |
It is worth noting that the expanded RAM model can still be published as an application template for subsequent one-click installation/upgrade/delivery of the entire business system.
Test and practice of importing existing Kubernetes applications
The following test is based on Rainbond v5.8. In order to test the import of existing applications in Kubernetes, I plan to wpuse the Wordpressstation building system that has been deployed in the namespace to conduct an import test. The system consists of the following resources:
[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 to import resources wp. The platform will group resources according to label:
Rainbond divides applications according labelto . For example , theapp.kubernetes.io/name:wp-mysql resources that match or will be distributed to two different applications in the figure, and those that do not have the above resources 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 you must plan carefully before importing, and add reasonable ones .app:wordpresslabellabel
During the import process, Rainbond assigns different properties to the extended model for management. Most of the operation and maintenance operations have become very easy to use, while the other part is managed by the Kubernetes property page.
Once imported, wordpressand wp-mysqlboth applications can be managed using Rainbond.
- Port management
wordpressBefore importing, rely on the NodePorttype of Serviceexternal exposure, but after importing Rainbond management, you can use the gateway to expose your own port 80 to the outside world. Note that you must restart the wordpressservice for the access policy to take effect.
For some services, the access entry does not support dynamic designation, which requires some changes on the business side to adapt to the new access entry. WordpressFor , the site address in the general options needs to be redefined.
- Storage management
The wordpresssystem uses the hostpathmode of storage for all components. Although this configuration is simple, it is not suitable for large-scale Kubernetes environments Podthat may drift. After Rainbond is deployed, it will provide easy-to-use shared storage, which supports data sharing among 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 new and old paths and perform a data migration.
practical meaning
Through the application model, IT technicians can pay more attention to the business itself, rather than the use of the underlying complex tools. The final effect is to simplify the operation cost and difficulty of understanding, and make Kubernetes easier to implement.