You need to be familiar with Kubernetes concepts for more specialized use of the ArvanCloud Cloud Container. Throughout this guide, we will talk about the Arvan cloud container utilizing these concepts. Unless you are thoroughly familiar with Kubernetes, we recommend you first refer to “An Expert’s Guide to Cloud Container and Kubernetes for Beginners” and then explore this guide.
Introduction
The ArvanCloud Container service has been developed and implemented based on the Community version of the OpenShift platform, which in turn is powered by Kubernetes.
Generally, nearly all the features of Kubernetes are supported in OpenShift and only there are some differences, such as the use of OpenShift Route rather than Kubernetes Ingress or the option to define build in OpenShift.
Furthermore, there are certain limitations for this service because of the implementation of it as a cloud service in the different services of ArvanCloud, which we will discuss in the next section.
You will have to use the ArvanCloud command line if you wish to use the ArvanCloud Cloud Container. For this purpose, download the ArvanCloud command line for your Linux or Mac operating system, add it to your PATH, and then make it executable. After that, create a new key or use one of your existing keys in the panel’s Settings > API Keys section. In conclusion, use the Login command in the command line of your operating system to log in:
You can access all commands that can be executed using ArvanCloud’s command line using the paas subcommand:
The paas subcommand line of ArvanCloud is built based on oc and kubectl, and all of the commands are compatible with their commands.
While the cloud Container command line communicates with the central server through Kubernetes standard APIs, because of the unique authentication structure of the ArvanCloud and the modifications implemented to improve the user experience in the command line, using kubectl or oc directly is not recommended or supported by us.
Cloud Container Limits Compared to Kubernetes
1- Kubernetes API Version
Be aware that ArvanCloud ‘s Cloud Container service is currently based on OpenShift version 3.11, which itself is powered by Kubernetes version 1.11. As a result, all supported APIs will refer to this version. (In the future, as OpenShift Community introduces new versions, datacenters using new versions will also be made available).
2- Cluster Level Access
When compared to the on-premise version of the Kubernetes platform you implemented yourself, an important limitation of the cloud Container is the lack of access on the Cluster Administration level. Within the ArvanCloud Cloud Container, each user is restricted to their project (each project represents a namespace), and you can define access levels only within that project.
This restriction will prevent you from being able to implement Kubernetes features which require cluster-level access in the Container. As an example, you cannot define CRD on the cluster itself or deploy service meshes such as istio.
3- Limit and Request Defining Restriction
Your next restriction is the inability to define a pod without limiting resources. Within the ArvanCloud Cloud Container, you have to register limit and request values in all pods and deployments with equal values for CPU, memory and ephemeral storage resources (QoS class QoS class of Guaranteed). This is because the service could be offered as Pay As You Go. This means any amount of resources used up as your resource limit in the pods while they are in the “Running” state would be deducted from your user account based on the cloud container rates.
Other basic Kubernetes resources and concepts like deployment, statefulset, secret, service, along with OpenShift-specific concepts like route and build are all supported in the ArvanCloud Cloud Container. You can refer to the Cloud Container Guide section for tutorials on these concepts.
Catalog and Ready-to-Use Software
There is a catalog section in the Cloud Container panel of ArvanCloud that has been built based on the OpenShift service catalog, allowing you to build complex software using a template. The user needs to create a service instance with its parameters to build software based on this template, all of which can be done through the panel.
Remember that deleting any entity created by the catalog is ineffective and will be created again after some time. For instance, when you delete a Redis deployment created with a catalog, it will be created again. This is why we suggest using the panel to create and delete this software, because finding the relationship between these entities is a bit difficult.
When you want to delete the software created with the catalog through the command line, deleting the respective service instance will delete all the created entities.