BUILD HIGH AVAILABILITY VIDEO

CONVERENCE SERVICE WITH KUBERNETES

CLUSTER ACROSS DATA CENTER

Basma Fathan Mubina Bandung, West Java

school of electrical engineering basmafathan@student.telkomuniversity
Telkom University .ac.id
 Abstract— Video conferencing has become a popular determines the number of pods that need to function on the
activity for today's society along with the development of node.
technology. With increasing user traffic, it is not uncommon
for these services to experience downtime. To avoid this, an A. Horizontal Pod Autoscaler
infrastructure that can replicate itself is built so that downtime
Horizontal Pod Autoscaler works automatically to scale
can be avoided. (Abstract)
the number of pods in replication controller, deployment,
Keywords— Kubernetes, High Availability. Video replica set based on CPU usage or Memory used. This type
Conference, Horizontal Pod Autoscale, Data Center of autoscaler is only able to scale certain objects such as
DaemonSets [2].
I. INTRODUCTION
The autoscaler must be configured to specifications not
The increase in traffic generated by users of this service
exceeding the maximum available CPU and Memory
is very high, leading to the fact that the server's resources
capacity limits. This is so that the autoscaler can be run
are gradually being exhausted. When resources are
before the first pod reaches its maximum limit. If the HPA
exhausted, the video conference service will experience
configuration has the same value as the memory and CPU
downtime and users will not be able to access the
configuration, or the CPU and memory usage of the first
application. To prevent this, System Administrator /
pod reaches the maximum limit, what will happen is that the
DevOps can use Kubernetes as one of the containerized
first pod will restart automatically and a replica pod will not
platform options to maintain high availability services and
be created.
adjust the amount of resources the server receives.
B. Metrics Server
Kubernetes is an open source container platform that
can manage the workloads of a containerized application[1]. In order to be able to run Horizontal Pod Autoscaler,
Kubernetes has many advantages. The first advantage is that where HPA uses the Aggregate metricserver API, it is
Kubernetes is more efficient than . New containers will be necessary to deploy the metrics server in the same cluster.
added on nodes that have more space. The second advantage The function of the Metrics server is to monitor resource
is selfhealing. If your Kubernetes cluster crashes, you can usage in Kubernetes [3] . The number of pod replicas can be
recover it automatically. The third advantage is ease of determined by observing the CPU values in yaml
maintenance. Containers can be moved to other nodes deployment. The formula for determining the number of
during maintenance. The fourth advantage is automatic replicas is as follows :
scaling. The number of nodes automatically increases or
decreases according to user needs and CPU utilization to
meet the required demand. In this paper, the discussion will (4)
focus on the fourth advantage, namely automatic scaling.
Kubernetes has introduced a new infrastructure called III. ANALYSIS DESIGN AND RESULTS
microservices. Microservices work by dividing an In this test,
application into smaller parts, each part performing different
tasks at the same time. By sharing these services, you can A. SPESIFIKASI PERANGKAT
avoid downtime.
Percobaan dilakukan menggunakan empat macam spesifi
This white paper builds a highly available infrastructure kasi yang berbeda. Spesifikasi yang pertama adalah hardware
where the infrastructure runs on a Kubernetes cluster. This PC yang digunakan selama percobaan. Untuk lebih jelasnya,
infrastructure is based on an open source based video dapat dilihat melalui table 1
conferencing application. The second part describes how to
Komponen Spesifikasi
set up your infrastructure. The third section describes how to
perform the test and get the test results. Finally, Part 5 CPU 4.10 GHz
describes the overall conclusions of the work.identified in ita
lic type, within parentheses, following the example. Some co RAM 16 GB
mponents, such as multi-leveled equations, graphics, and tabl
es are not prescribed, although the various table text styles ar Fig. 1. PC hardware specifications
e provided. The formatter will need to create these componen
ts, incorporating the applicable criteria that follow. Sedangkan untuk spesifikasi worker node dan master node,d
apat dilihat melalui table 2, table 3, dan table 4.
II. SYSTEM ARCHITECTURE
Komponen Spesifikasi
The cAdvisor may monitor the number of metrics used
on the node (CPU utilization in this experiment) with
kubelet. Once the CPU utilization is known on the worker IP 128.199.113.122
node, this information is forwarded to the metrics server. The
task of the Metrics Server is to collect CPU utilization Hostname basma-master
information from all worker nodes in the Kubernetes cluster.
This information is passed to the horizontal pod autoscaler as CPU 2 Core
a Kubernetes function. This autoscaler has the ability to
decide whether to add / remove pods. The pods then
automatically scale up (increase the number of pods) or scale Memory 2 GB
down (decrease the number of pods), and the replicaSet
Fig. 2. Master node specifications

Komponen Spesifikasi

IP 188.166.239.12

Hostname basma-jones-worker-node1 apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler
CPU 1 Core metadata:
name: test-spreed-webrtc
namespace: default
Memory 1 GB spec:
scaleTargetRef:
kind: Deployment
Fig. 3. Worker node specification (DigitalOceans server) apiVersion: apps/v1
maxReplicas: 4
B. SYSTEM DESIGN minReplicas: 1
The system is created by first creating a Kubernetes metrics:
cluster consisting of two different servers, two worker nodes - type: Resource
and one master node, DIgitalOceans and Linode. WebRTC resource:
name: cpu
services are built using a fileyaml distribution where target:
kubescheduler automatically determines where WebRTC type: Utilization
services will be deployed. In this test, WebRTC is averageUtilization: 80
automatically deployed on the Linode server node. See behavior:
Table 4 for WebRTC deployment files. scaleDown:
policies:
- type: Pods
root@ basma-master:~# kubectl test-spreed-webrtc.yaml -- value: 4
port=8443 --target-port=8443 --name=my-spreed-webrtc -- periodSeconds: 10
- type: Percent
external-ip=128.199.113.122 value: 10
Fig. 4. Command to deployment WebRTC service Fig. 6. Command to expose service using external IPperiodSeconds: 60
selectPolicy: Min
After successfully deploying WebRTC, we need to expose In this experiment, autoscalling stabilizationWindowSeconds:
is only targeted at cpu 300
theapiVersion:
use of theautoscaling/v2beta2
external IP address and port determined by usage. This is because the experiments carried out, namely
scaleUp:
kind: HorizontalPodAutoscaler
WebRTC so that others can access our service. You can use stress testing, will focus on the extent to which WebRTC
policies:
themetadata:
commands in Table 5 for setting. can accommodate the given request. Whether - type: Podsor not
name: test-spreed-webrtc WebRTC is strong in accommodating incoming value:requests
5
root@ basma-master:~#
namespace: default kubectl test-spreed-webrtc.yaml -- depends on CPU usage. This focuses on the periodSeconds:
memory usage 10
spec:
port=8443 --target-port=8443 --name=my-spreed-webrtc -- of the currently running WebRTC process- type: andPercent
does not
scaleTargetRef: value: 12
external-ip=128.199.113.122 affect the number of incoming requests.
kind: Deployment periodSeconds: 10
apiVersion:
Fig. 5. Commandapps/v1
to expose service using external IP C. NETWORK PERFORMANCE EXPERIMENT selectPolicy: Max
maxReplicas: 4 stabilizationWindowSeconds: 0
QoS analysis is required to see the network performance
minReplicas: 1
metrics: of a running application. QoS tests are performed by monito
The next step that needs to be done is to deploy Horizontal ring the logs collected by Wireshark. Protocols captured by
- type:
Pod Resource(HPA). In order for HPA to be formed, a
Autoscaler
resource: Wireshark include UDP, TCP and TLS. UDP [5] as a transpo
name: cpu QoS Parameters rt protocol for WebRTC media running at Layer 4 (Transport
Threads
target: HPA Through
Jitter delay
Packet Layer). In this test, the protocol analyzed is a UDP type prot
type: Utilization put loss ocol. This protocol was chosen because video conference act
No Witho 80
averageUtilization: ivity is performed on transport media. QoS analysis is perfo
2.697
threads
behavior: ut 0 ms 13 ms -0,04% rmed by testing the QoS configured in the HPA before and a
kbit/s
scaleDown: HPA fter the thread is served.
500
policies: With 3.572
0 ms 5 ms -0,19% Fig. 7. Comparison of QoS parameters before and after given threads
- type: PodsHPA kbits/s
previously
value: 4 configured yaml file is needed. The configuration
Berdasarkan hasil percobaan diatas, didapatkan bahwa nilai t
ofperiodSeconds:
the yaml file can
10 be seen in table 6
- type: Percent hroughput sebelum diberi threads dan tanpa adanya HPA ada
value: 10 lah sebesar 2.697 kbits/s dimana angka ini lebih kecil jika dib
periodSeconds: 60 andingkan dengan setelah diberi threads sebesar 500 yaitu m
selectPolicy: Min enjadi 3.572
stabilizationWindowSeconds: 300
D. EXPERIMENTAL STRESS TESTING
scaleUp:
policies: Stress testing belongs to performance testing, which
- type: Pods aims to find out how much load an application can absorb
value: 5
periodSeconds: 10
- type: Percent
value: 12
periodSeconds: 10
selectPolicy: Max
stabilizationWindowSeconds: 0
[6]. In this test, the stress test is performed using three
different ramp time parameters. That is, when the ramp
time is 10, 30, and 100 seconds. The number of threads
tested is 100,500, which is a multiple of 50.
Fig. 8. Picture Error rate when ramp of time = 10 seconds
At 10 seconds, you can see that no errors have occurred in
100 threads and 150 users. If you have 200 user threads, the
error rate is 1% when tested without HPA.
CONCLUSION
From this paper, it could be concluded that despite the fact
that WebRTC is accessed with a big quantity of threads
(100-500 users), the utility can run nicely in phrases of
delay, jitter, throughput and packet loss. After doing
pressure testing, it could be concluded that using HPA isn't
always suitable if the person does now no longer tolerate the
mistake price, that is due to the fact on the time of Scale up
and Scale Down the pod will arise an mistakess wherein
while making the pod to shape a replica, it takes time. One
manner to lessen the mistake price while the use of HPA is
to growth the quantity of ramps of time at the JMeter
because the load generator.
REFERENCES
[1] Galantino, “Enabling Job Aware Scheduling on Kubernetes Cluster,”
POLITECNICO DI TORINO, 2020.
[2] T. Nguyen, Y. Yeom, T. Kim, D. Park, and S. Kim, “Horizontal Pod
Autoscaling in Kubernetes for Elastic Container Orchestration,” pp.
1–18, 2020, doi: 10.3390/s20164621.
[3] Hu, Tengfei and Wang, Yannian, “A Kubernetes Autoscaler Based on
Pod Replicas Prediction” in Asia-Pacific Conference on
Communications Technology and Computer Science (ACCTCS),
2021.
[4] Abhishek Verma, Luis Pedrosa, Madhukar Korupolu, David
Oppenheimer, Eric Tune, and John Wilkes. 2015. Large-scale cluster
management at Google with Borg. In Proceedings of the Tenth
European Conference on Computer Systems (EuroSys '15).
Association for Computing Machinery, New York, NY, USA, Article
18, 1–17.
[5] Definition and Analysis of WebRTC Performance Parameters as well
as Conception and Realization of an End-to-End Audio Quality
Monitoring Solution for WebRTC-Based "immmr" Call Scenarios
[6] A. Jacob and K. A., “Scrutiny on Various Approaches of Software
Performance Testing Tools,” Int. Conf. Electron. Commun. Aerosp.
Technol., vol. 2, 2018.