Installation and Deployment
Overview
This chapter describes how to install and deploy the Rubik component.
Software and Hardware Requirements
Hardware
- Architecture: x86 or AArch64
- Drive: 1 GB or more
- Memory: 100 MB or more
Software
- OS: openEuler 22.03-LTS-SP1
- Kernel: openEuler 22.03-LTS-SP1 kernel
Environment Preparation
- Install the openEuler OS. For details, see the openEuler 22.03-LTS-SP1 Installation Guide.
- Install and deploy Kubernetes. For details, see the Kubernetes Cluster Deployment Guide.
- Install the Docker or iSulad container engine. If the iSulad container engine is used, you need to install the isula-build container image building tool.
Installing Rubik
Rubik is deployed on each Kubernetes node as a DaemonSet. Therefore, you need to perform the following steps to install the Rubik RPM package on each node.
Configure the Yum repositories openEuler 22.03-LTS-SP1 and openEuler 22.03-LTS-SP1:EPOL (the Rubik component is available only in the EPOL repository).
# openEuler 22.03-LTS-SP1 official repository name=openEuler22.03-LTS-SP1-Epol baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP1/EPOL/$basearch/ enabled=1 gpgcheck=1 gpgkey=https://repo.openeuler.org/openEuler-22.03-LTS-SP1/everything/$basearch/RPM-GPG-KEY-openEuler# openEuler 22.03-LTS-SP1:EPOL official repository name=Epol baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP1/EPOL/$basearch/ enabled=1 gpgcheck=0Install Rubik with root permissions.
sudo yum install -y rubik
Note:
Files related to Rubik are installed in the /var/lib/rubik directory.
Deploying Rubik
Rubik runs as a container in a Kubernetes cluster in hybrid deployment scenarios. It is used to isolate and restrict resources for services with different priorities to prevent offline services from interfering with online services, improving the overall resource utilization and ensuring the quality of online services. Currently, Rubik supports isolation and restriction of CPU and memory resources, and must be used together with the openEuler 22.03-LTS-SP1 kernel. To enable or disable the memory priority feature (that is, memory tiering for services with different priorities), you need to set the value in the /proc/sys/vm/memcg_qos_enable file. The value can be 0 or 1. The default value 0 indicates that the feature is disabled, and the value 1 indicates that the feature is enabled.
sudo echo 1 > /proc/sys/vm/memcg_qos_enable
Deploying Rubik DaemonSet
- Use the Docker or isula-build engine to build Rubik images. Because Rubik is deployed as a DaemonSet, each node requires a Rubik image. After building an image on a node, use the docker save and docker load commands to load the Rubik image to each node of Kubernetes. Alternatively, build a Rubik image on each node. The following uses isula-build as an example. The command is as follows:
isula-build ctr-img build -f /var/lib/rubik/Dockerfile --tag rubik:1.0.0 .
- On the Kubernetes master node, change the Rubik image name in the /var/lib/rubik/rubik-daemonset.yaml file to the name of the image built in the previous step.
...
containers:
- name: rubik-agent
image: rubik_image_name_and_tag # The image name must be the same as the Rubik image name built in the previous step.
imagePullPolicy: IfNotPresent
...
- On the Kubernetes master node, run the kubectl command to deploy the Rubik DaemonSet so that Rubik will be automatically deployed on all Kubernetes nodes.
kubectl apply -f /var/lib/rubik/rubik-daemonset.yaml
- Run the kubectl get pods -A command to check whether Rubik has been deployed on each node in the cluster. (The number of rubik-agents is the same as the number of nodes and all rubik-agents are in the Running status.)
[root@localhost rubik]# kubectl get pods -A | grep rubik
NAMESPACE NAME READY STATUS RESTARTS AGE
...
kube-system rubik-agent-76ft6 1/1 Running 0 4s
...
- Alternatively, after installing Rubik, you can run the /var/lib/rubik/build_rubik_image.sh script to automatically build a Rubik container image. This requires the Docker component to be installed in advance.
Common Configuration Description
The Rubik deployed using the preceding method is started with the default configurations. You can modify the Rubik configurations as required by modifying the config.json section in the rubik-daemonset.yaml file and then redeploy the Rubik DaemonSet. The following describes some common configurations. For other configurations, see Rubik Configuration Description.
Automatic Configuration of Pod Priorities
If automatic pod awareness is enabled, you only need to specify the priority using annotations in the YAML file when deploying the service pods. After being deployed successfully, Rubik automatically detects the creation and update of the pods on the current node, and sets the pod priorities based on the configured priorities.
Automatic Verification of Pod Priorities
Rubik supports consistency check on the pod QoS priority configurations of the current node during startup. It checks whether the configuration in the Kubernetes cluster is consistent with the pod priority configuration of Rubik. This function is disabled by default. You can enable or disable it using the autoCheck option. If this function is enabled, Rubik automatically verifies and corrects the pod priority configuration of the current node when it is started or restarted.
Configuring Rubik for Online and Offline Services
After Rubik is successfully deployed, you can modify the YAML file of a service to specify the service type based on the following configuration example. Then Rubik can configure the priority of the service after it is deployed to isolate resources.
The following is an example of deploying an online Nginx service:
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: qosexample
annotations:
volcano.sh/preemptable: "false" # If volcano.sh/preemptable is set to true, the service is an offline service. If it is set to false, the service is an online service. The default value is false.
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "1"
requests:
memory: "200Mi"
cpu: "1"
