Welcome to our new blog post series on Kubernetes! In this series, we will explore the world of Kubernetes deployment on top of Zadara, and how it can be used to manage containerized applications in our AWS-compatible cloud. We will cover a wide range of topics, from the basics of Kubernetes and container orchestration to more advanced topics like scaling, resiliency, and life cycle management. We will also dive into the different ways Kubernetes can be deployed and customized on top of zCompute per customer needs.
Whether you’re new to Kubernetes or an experienced user, this series will provide you with valuable insights and best practices for managing your containerized applications in the Zadara cloud. Stay tuned for more exciting content!
Our first blog post will focus on Kubernetes on cloud environments in general, and on the Zadara cloud in particular. While this blog post will not encompass all of the Kubernetes aspects with regards to history, functionality & operations (which probably requires its own blog series..), we will drill into key elements of the Kubernetes cloud integration and how they relate to the Zadara Compute cloud environment (zCompute).
Background
Apart from being the de-facto standard for container orchestration, Kubernetes is often described as “the Operating System of the Cloud”, a term which expresses the fact that more than any other application, it utilizes the power of the cloud by interacting with its core services but at the same time abstracting the cloud’s API with the Kubernetes API.
Such masking of the cloud-level services with Kubernetes-level resources enables users to focus on their application-level needs rather than the specific cloud specifications – this is the root capability beneath the multi-cloud methodology, but even for single-cloud use-cases Kubernetes becomes the platform of choice for developers which no longer need to know the details of the cloud which runs their workloads.
Equipped with native compute, load balancing, storage and even dynamic scaling cloud integrations, Kubernetes users enjoy the power of the cloud without having to directly interact with it. In this blog post we will explore these benefits on top of the Zadara cloud using well-known Kubernetes artifacts, industry-standards deployment tools, and best-practices usage procedures.
Kubernetes on Clouds
Keeping in mind that Kubernetes is not a regular application but rather a complex platform, consisting of many different services and encompassing various aspects of containerized application delivery (with and without direct relation to cloud services), it has become apparent that mastering it requires quite a lot of learning effort – with regards to usage (the data-plane) as well as internal administration (the control-plane). More specifically and unlike day-to-day Kubernetes usage, the initial deployment of Kubernetes over clouds does require intimate cloud-level knowledge (as well as elevated permissions), so cloud vendors were quick to offer various degrees of managed-Kubernetes offerings, including the following:
Offering type | Control-plane | Data-plane |
Self-managed | User responsibility | User responsibility |
Semi-managed | Cloud responsibility | User responsibility |
Fully-managed | Cloud responsibility | Cloud responsibility* |
* Cloud responsibility over the data-plane means the user is not concerned with the underline compute resources for their workload (only on the pod-level specification).
In addition, while Kubernetes was the first Cloud-native application (donated by Google to be the first CNCF project in 2016), its cloud API integrations matured over the years from in-tree support baked within its source code into externally supported tools per cloud vendor and services. For example, the Kubernetes built-in AWS cloud support was removed in version 1.26 (and for all other cloud vendors in version 1.29), so the basic cloud integration component (Cloud Controller Manager) needs to be deployed separately from the core Kubernetes components. This paradigm shift affects other areas as well, such as storage and load balancing – as they now require dedicated external utilities to handle cloud-specific APIs.
As a result of this change, cloud vendors are using downstream distributions of the original Kubernetes project, bundling their specific cloud’s tools together with the vanilla Kubernetes artifacts to create a streamlined experience for their cloud.
Kubernetes on AWS
After years of users running self-managed Kubernetes deployments and workloads on top of AWS, in 2018 Amazon introduced EKS (Elastic Kubernetes Service) – their semi-managed offering which was also integrated with Fargate in 2019 to create a fully-managed offering.
In 2020 AWS open-sourced EKS-D, their own Kubernetes distribution used by EKS, in order to facilitate EKS-like Kubernetes clusters outside of AWS.
Since EKS-D is the basis for all AWS Kubernetes services, using it ensures you can run the same Kubernetes components both inside and outside of AWS – including other cloud vendors or on-premise locations. Still, you will only get the full EKS-like experience with the AWS cloud, as the AWS-oriented components only work with the AWS cloud API.
Among others, EKS-D include the below components – all tested by AWS and validated to work with EKS in a consolidated versioned bundle:
- Core components (like APIServer and ETCD)
- Basic plugins (like CoreDNS and kube-proxy)
- CSI components (like external-provisioner and external-attacher)
- CSI snapshotting (like snapshot-controller and csi-snapshotter)
Kubernetes on Zadara
The Zadara cloud differs from public clouds like AWS mostly due to its edge nature – rather than a few huge data-centers (regions) we offer over 500 small-sized edge locations, each of them fully independent, providing either private- or hybrid-cloud capabilities.
For advanced distributed computing, running your workload on multiple clouds (each one independent yet similar in nature) ensures resiliency and fits the multi-cloud strategy for Kubernetes deployment. One major incentive is that instead of investing in different cloud vendors’ APIs (AWS vs. GCP vs. Azure, etc.), customers can control numerous clouds with the same AWS API.
Our unique offering enables MSPs as well as end-users with the dynamic nature of public cloud methodologies while preserving the on-premise advantages of tenant-oriented, low latency and direct networking.
As the Zadara cloud is AWS-compatible by nature, it is a perfect fit for running EKS-D workflows outside of AWS, while enjoying the EKS-like experience with regards to all major cloud integrations. While there are some adjustments to be made (for example with regards to the cloud’s endpoints which are not the AWS ones), Zadara supports the same AWS-oriented utilities such as the AWS CCM, the AWS EBS CSI driver and the AWS Load Balancer Controller. Zadara also supports Kubernetes-native tools that support AWS, like the Kubernetes Cluster Autoscaler which utilizes the AWS Auto-Scaling Groups API.
In addition to the EKS-D compatibility, the Zadara cloud supports standard cloud automation tools such as Terraform (or its new OpenTofu alternative) using the official AWS provider, as well as Packer for AMI-based image building. Such infrastructure-as-code (IaC) approach enables our users to create complex yet consistent architectures for various teams and customers, which is a key attribute in any self-managed Kubernetes deployment.
Over the last few years we’ve utilized our built-in capabilities to create various reference architectures for different Kubernetes solutions – including Vanilla (original Kubernetes), RKE2 (Rancher-based distribution) and more recently EKS-D itself. We’ve seen several of our customers constructing their own Kubernetes services following these instructions, and we feel like EKS-D is the right approach for Kubernetes on top of Zadara as it benefits the most from our AWS compatibility.
Stay tuned for the next blog post in this series, discussing Zadara’s highly-customizable solution for a self-managed EKS-D cluster automated deployment!
