The SkyWalking Cloud on Kubernetes is proposed in order to:
If the user of SkyWalking decided to deploy it into Kubernetes, there’re some critical challenges for them.
First of them is the complex of deployment, it doesn’t only mean the OAP server and storage cluster, but also include configuring target cluster to send data to backend. Then they might struggle to keep all of them reliable. The size of the data transferred is very big and the cost of data stored is very high. The user usually faces some problems, for instance, OAP server stuck, Elasticsearch cluster GC rate sharply increases, the system load of some OAP instances is much more than others, and etc.
With the help of CRDs and the Controller, we can figure out the above problems and give users a more pleasing experience when using SWCK.
I proposed two crucial components for SWCK, backend operator and target injector. The first one intends to solve the problems of the backend operation, and another focus on simplifying the configuration of the target cluster.
They should be built as two separate binary/image, then are installed according to user’s requirements.
The operator might be a GO application that manages and monitors other components, for example, OAP pods, storage pods(ES, MySQL, and etc.), ingress/entry and configuration.
It should be capable of HA, performance, and scalability.
It should also have the following capabilities:
The above items should be accomplished in several versions/releases. The developer should sort the priority of them and grind the design.
The injector can inject agent lib and configuration into the target cluster automatically, enable/disable distributed tracing according to labels marked on resources or namespace.
It also integrates backend with service mesh platform, for example, Istio.
It should be a GO application and a GO lib to be invoked by swctl to generate pod YAMLs manually.