Kubernetes (K8s) is one of the leading platforms for deployment and management of fault-tolerant containerized applications. It is used to build cloud-native, microservice applications, as well as enables companies to migrate existing projects into containers for more efficiency and resiliency. K8s cluster can handle complex tasks of container orchestration, such as deployment, service discovery, rolling upgrades, self-healing, and security management.
Kubernetes project is supported by Cloud Native Computing Foundation that helps to enable cloud portability without vendor lock-in. The K8s clusters can be deployed anywhere: on bare metal, public or private cloud.
At the same time, we don’t need to forget that spinning up Kubernetes cluster on own servers from scratch is a complicated procedure. It requires a deep understanding of the cluster components and ways they should be interconnected, as well as time and skills for monitoring and troubleshooting. For more details refer to Kubernetes The Hard Way article.
In addition, managed K8s services automate and ease a list of operations but there still remains the “right-sizing” cloud problem. To get maximum efficiency I have to predict the size of a worker node and containers running inside. Otherwise, I may end up paying for large workers that are not fully loaded, or using small VMs and playing around automatic horizontal scaling which may lead to additional complexity.
CloudJiffy has moved ahead solving a number of barriers and providing necessary functionality to get started with Kubernetes hosting easily while gaining maximum efficiency in terms of resource consumption:
- Complex cluster setup is fully automated and converted to “one click” inside intuitive UI
- Instant vertical scaling based on the load changes fully automated by the platform
- Fast automatic or manual horizontal scaling of K8s worker nodes with integrated autodiscovery
- Pay-per-Use pricing model is unlocked for Kubernetes hosting, thus there is no need to overpay for reserved but unused resources
- CloudJiffy Shared Storage is integrated with Dynamic Volume Provisioner so physical volumes used by applications are automatically placed to the storage drive and can be accessed by the user using SFTP/NFS or via integrated file manager
- No Public IPs are required by default, Shared Load Balancer processes all incoming requests as a proxy server and is provided out of the box
- Provision the clusters across multiple regions, clouds and on-premises with no fractions and differences in configurations and no vendor lock-in
CloudJiffy PaaS supplies Kubernetes cluster with the following pre-installed components:
- Runtime controller Containerd
- CNI plugin (powered by Weave) for overlay network support
- Traefik ingress controller for transferring HTTP/HTTPS requests to services
- HELM package manager to auto-install pre-packed solutions from repositories
- CoreDNS for internal names resolution
- Dynamic provisioner of persistent volumes
- Dedicated NFS storage
- Metrics Server for gathering stats
- CloudJiffy SSL for protecting ingress network
- Web UI Dashboard
Explore the Kuberenetes cluster installation steps from the video or instruction below.
Kubernetes Cluster Installation
1. To get started, log in to the dashboard, find the Kubernetes Cluster in the Marketplace and click Install.
Or import the manifest from GitHub using the link:
https://github.com/jelastic-jps/kubernetes/blob/master/manifest.jps
2. Сhoose the type of installation:
- Clean Cluster with pre-deployed Hello World example
- Deploy custom helm or stack via shell commands.
Type a list of commands to execute helm chart or other commands for a custom application deployment.
By default, here I are offered to install Open Liberty application server runtime with a predefined set of commands:
- Adding repository
helm repo add ibm-charts https://raw.githubusercontent.com/IBM/charts/master/repo/stable/
- Installing Open Liberty from this repository
helm install --name default --set autoscaling.enabled=true --set autoscaling.minReplicas=2 ibm-charts/ibm-open-liberty --debug
- Applying manifest
kubectl apply -f https://raw.githubusercontent.com/jelastic-jps/kubernetes/master/addons/openliberty.yaml
3. As a next step, choose the required topology of the cluster. Two options are available:
- Development: one master (1) and one scalable worker (1+) – lightweight version for testing and development purposes
- Production: multi master (3) with API balancers (2+) and scalable workers (2+) – cluster with pre-configured high availability for running applications in production
Where:
-
- Multi master (3) – three master nodes.
- API balancers (2+) – two or more load balancers for distributing incoming API requests. In order to increase the number of balancers, scale them out horizontally.
- Scalable workers (2+) – two or more workers (Kubernetes nodes). In order to increase the number of workers, scale them out horizontally.
4. Attach dedicated NFS Storage with dynamic volume provisioning.
By default, every node has its own filesystem with read-write permissions but for access from other containers or persisting after redeployments, the data should be placed to a dedicated volume.
I can use custom dynamic volume provisioner by specifying the required settings in my deployment yaml files.
Or, I can keep already pre-configured volume manager and NFS Storage built-in to CloudJiffy Kubernetes cluster. As a result, the physical volumes are going to be provisioned dynamically on demand and connected to the containers. Storage Node can be accessed and managed using file manager via dashboard, SFTP or any NFS client.
5. In order to highlight all package features and peculiarities, we initiate the installation of the Open Liberty application server runtime in Production Kubernetes cluster topology with built-in NFS Storage.
Click the Install button and wait a few minutes. Once the installation process is completed the cluster topology looks as follows:
6. I can access Kubernetes administration dashboard along with Open Liberty application server welcome page from the successful installation window.
- use Access Token and follow Kubernetes dashboard link to manage Kubernetes cluster
- access Open Liberty welcome page by pressing Open in Browser button
Remote API Access to Kubernetes Cluster
In order to access and manage the created Kubernetes cluster remotely using API, tick the Enable Remote API Access checkbox.
The Remote API Endpoint link and access Token should be used to access Kuberntes api-server (Balancer or Master node).
The best way to interact with api-server is using the Kubernetes command line tool kubectl:
- Install the kubectl utility on my local computer following the official guide. For this article, we have used installation for Ubuntu Linux.
- Then create local configuration for kubectl. To do this open terminal on my local computer and issue the following commands:
$ kubectl config set-cluster mycluster --server={API_URL}
$ kubectl config set-context mycluster --cluster=mycluster
$ kubectl config set-credentials user --token={TOKEN}
$ kubectl config set-context mycluster --user=user
$ kubectl config use-context mycluster
Where:
{API_URL} – Remote API Endpoint link
{TOKEN} – Access Token
Now I can manage my Kubernetes cluster from local computer just following the official tutorial.
As an example, let’s take a look at the list of all available nodes in our cluster. Open local terminal and issue a command using kubectl:
user@jelastic:~$ kubectl get nodes
In order to disable/enable API service after installation use Master node Configuration Add-On.
Kubernetes Upgrade
To keep my Kubernetes cluster software up-to-date use the Configuration Add-On. Just click on the Upgrade button. Addon checks whether new version is available or not and if so the new version will be installed. During the upgrade procedure all the nodes including masters and workers will be redeployed to new version one by one, all the existing data and settings will remain untouched. Keep in mind that upgrade procedure is sequential between versions so if I perform an upgrade to the latest version from the version far away behind the latest one I will have to run upgrade procedure multiple times. The upgrade becomes available only if new version becomes available and was globally published by the CloudJiffy team.
In order to avoid downtime of my applications during the redeployment please consider using of multiple replicas for my services.
Statistics and Pay-per-Use Billing
CloudJiffy provides automatic vertical scaling for each worker and master node in the Kubernetes cluster, thus the required resources are allocated on demand based on the real-time load. As a result, there is no need to monitor the changes all the time as the system makes it for me. In addition, there is a convenient way to check current load across a group of nodes or each node separately. Just press the Statistics button next to the required layer or specific node.
Such highly-automated scaling and full containerization of CloudJiffy PaaS enables a billing model that is considered relatively new for cloud computing. Despite the novelty, this model has already gained a reputation of the most cost-effective “pay-per-use” or so-called “pay-as-I-use” approach. As a result, the payment for Kubernetes hosting within the platform is required only for the actually used resources with no need to overallocate thus solving the “right-sizing” problem inherent from the first generation of cloud computing pricing (“pay-per-limits” or so-called “pay-as-I-go” approach).
The whole billing process is transparent and can be tracked via the dashboard (Balance > Billing History). Basically, the price is based on the number of real consumed resource unit cloudlet (128MiB + 400MHz). Such granularity provides more flexibility in bill forming, as well as clarity in cloud expenditures.
CloudJiffy PaaS allows automatic vertical scaling of Kubernetes cluster nodes, automatic horizontal scaling with auto-discovery of the newly added workers, management via intuitive UI, as well as implementation of the required CI/CD pipelines with Cloud Scripting and open API. For private setup, the platform can provision clusters across multiple clouds and on-premises with no vendor lock-in and with full interoperability across the clouds. It allows to focus the valuable team resources on the development of applications and services logic instead of spending time on adjusting and supporting infrastructure and API differences of each K8s service implementation. Try it out at one of public CloudJiffy PaaS service providers and share with us my feedback for further improvements!