Modern software engineering is becoming more and more complicated, especially in cloud-native environments like Kubernetes. There are countless moving parts and pieces and no two applications are built the same.

The larger the company, the more moving parts there are. With more moving parts, development cycles become stretched, onboarding developers takes longer, and the chances of mistakes increase. Because of this, companies stagnate and become slower to innovate and push new products and features.

The modern answer to this problem is Platform Engineering and, according to Gartner, 80% of software engineering organizations will establish platform teams by 2026.

In this blog we will discuss what platform engineering is and what can you do to stay ahead of the curve…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

What is platform engineering?​

Platform engineering acts like an internal product team, but instead of serving external customers, its primary users are the company's own developers and internal teams.

The job of platform engineers is designing and building toolsets, infrastructure, and workflows that make it easier for developers to build, test, deploy, and manage software. The goal is to create a unified platform, often called an Internal Developer Platform (IDP), which provides developers with self-service access to everything they need without depending on other teams, like operations or DevOps.

Why platform engineering?​

“The goal of Platform Engineering is to allow as much speed as possible, with as much safety as possible” ~ Jason Warner, CEO @ poolside, former CTO @ GitHub (source)

Platform engineering creates an abstraction layer that simplifies infrastructure management for developers. Instead of dealing with the complexities of infrastructure, developers can focus on writing code, leading to quicker onboarding and faster time to market.

A good IDP enables separation of concerns. Most of the time your DevOps teams and Product teams do not need to talk to each other and they can move independently. It also provides guard-rails and ensure standard and secure practices across the organization.

Fun fact: when Spotify built its own Internal Developer Platform (now known as Backstage) they realized that their developers were 5% more likely to stay at the company one year later. Developer experience matters!

Internal Developer Platforms (IDPs)​

When it comes to Internal Developer Platforms (IDPs), you typically have two options: build one yourself or buy an off-the-shelf solution.

Building your own may seem like the ideal choice. You can tailor it perfectly to your specific needs, ensuring it integrates with your existing tech stack, workflows, and infrastructure. However, building an IDP from scratch is both time-consuming and expensive, it’s essentially a full product in itself. For this reason, custom-built platforms are typically reserved for larger organizations with the resources to invest in such an undertaking.

On the other hand, off-the-shelf platforms offer a quicker, more affordable alternative. These platforms are designed to cater to a wide range of users and needs, which can be both a blessing and a drawback. You may end up with features you don’t need or find key functionality missing. In the latter case, you’re dependent on the vendor’s roadmap, which may not prioritize your needs. While they provide immediate value and are a solid starting point, you have to keep in mind that your organization will eventually outgrow them as your requirements evolve.

But, at Cyclops, we are building something in between…

Cyclops​

Cyclops is an open-source tool that bridges the gap between fully custom-built Internal Developer Platforms (IDPs) and off-the-shelf solutions. It enables you to build IDPs for Kubernetes in hours instead of months, providing the flexibility to tailor the platform to your specific needs without the high cost and time investment of building from scratch.

Cyclops enables your Platform teams to build custom user interfaces for configuring and deploying applications and services to Kubernetes clusters. It leverages Helm charts (learn more here) to generate these UIs. You can easily import any of your existing Helm charts into Cyclops as templates and create a user-friendly interface tailored to your specific needs.

The fields shown above are entirely customizable along with the validations. Cyclops allows you to define how much of configuration you want to expose to your developers, while the validations you put in place prevent them from making mistakes.

After a developer has configured the application, with a click of a button it is deployed to the cluster. Cyclops then displays all resources related to the application, offering easy access to relevant information, including logs, health checks, and status updates.

In a nutshell, Cyclops lets you provide the guard rails for your developers to safely deploy their application to Kubernetes and then overview the status of their apps.

Looking for more?​

Thanks for reading! In future blogs you can expect us going more in depth on Cyclops and how you can create some pretty fun stuff with it. If you enjoyed this article and are looking forward to more, remember to show your support by starring our repo ⭐🙏

Whether you are new to Kubernetes or maybe you're part of a startup that's always short on time, this guide is for you. Kubernetes is an incredibly powerful tool for managing containerized applications, but it's also notorious for its complexity and steep learning curve.

And if you're running a startup, you probably don't have the luxury of spending days (or weeks) wrestling with configuration files and cloud infrastructure. Setting up a Kubernetes cluster can feel like a daunting task, but it doesn't have to be.

This article will show you how to quickly spin up a Kubernetes cluster in the cloud and deploy your applications in just minutes. And we're making it a speedrun! In less than 10 minutes, you'll have everything up and running, including your own software.

Start your timers! ⏳

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

What is Civo?

Civo is a cloud service provider that allows you to quickly spin up Kubernetes clusters - it takes about 90 seconds to get it up and running! If you have ever tried spinning up a cluster on other cloud service providers (AWS, I'm looking at you 👈), it will be a refreshing experience to see how easy and fast it is with Civo.

Although Kubernetes is not Civo's only service, this article will mainly focus on it as it is the fastest setup I've encountered (apart from local setups).

How to spin up a Kubernetes cluster with Civo?​

The first step is to create an account on Civo (obviously 🫴). If it's your first time trying out Civo, they will provide you with $250 worth of credits! You can follow along for free and work with a real Kubernetes cluster running in the cloud. Even if you do not have the credits anymore, Civo will tell you the monthly cost of running your cluster, so you do not have to dread receiving the bill at the end of the month 😅

Once you have created your account, you should be greeted with the Civo dashboard. To set up your cluster, click the "Launch a new cluster" button or go to the Kubernetes tab, where you will find a similar button.

You will be taken to a screen that lets you customize the specifics of your cluster. Here, you can choose how many nodes you want, what sort of nodes (Standard, Performance, CPU Optimized, or RAM Optimized), firewall configuration, cluster type…

In the spirit of a speedrun, I'll leave it all on the default values (except the name, which I wanted to fit the theme 😁).

But before launching your cluster, let's stop at the Civo Marketplace (on the same screen). The Marketplace has lots of tools that can help you in various ways, and they will be deployed to the cluster upon its creation so you can use them instantly.

Under the Management tab, you can find Cyclops UI. Cyclops will allow you to deploy your apps to the cluster without any extra configuration. It only requires you to have a docker image of your apps. And Cyclops is open-source, so it won't impact your Civo bill!

You can select to install Cyclops just by clicking on it, and it should have the blue checkmark as it does on the image below.

Now that we have configured our cluster and included Cyclops, let's launch it! Click the "Create cluster" button on the bottom of the screen, and let's go!

How to access your Kubernetes cluster?​

After less than 2 minutes ⏳ (you can see the countdown when the cluster is being created), you will have your cluster up and running. You will talk to the Kubernetes API in that cluster to access it. For this, we will be using the terminal, but only a couple of commands will be needed before we can start deploying our applications.

The first thing is to install kubectl (you can find how to install it here). kubectl is the Kubernetes command-line tool used to interact with your cluster.

Once you installed kubectl, download the Kubeconfig file of your cluster. You can find it in the Cluster Information section.

Once downloaded, which takes about a second or two ⏳, go to your terminal and type in the following command:

export KUBECONFIG=<insert-path-to-the-downloaded-kubeconfig-file>

To check if we set the Kubeconfig correctly, run any kubectl command and see if it's interacting with the right cluster. For example:

kubectl get pods

NAME                                 READY   STATUS      RESTARTS   AGE
install-traefik2-nodeport-ku-4b5zn   0/1     Completed   0          1m
install-cyclops-kubernetes-s-md5mz   0/1     Completed   0          1m

Our Kubernetes cluster is up and running, but now we want to use it and deploy our applications to it, and for that, we will be using Cyclops.

What is Cyclops?

Cyclops is an open-source tool that allows you to deploy your applications through a UI, hiding all of the complexity of Kubernetes.

The UI is highly customizable and is generated from Helm charts (read more about it here). You can use any of your existing Helm charts, import them into Cyclops as templates, and get a UI made for your specific use.

For now, we will be using the default templates that all Cyclops instances get out of the box (it is a speedrun, after all ⏳)

Deploying Applications to Kubernetes​

We selected Cyclops in the Marketplace when creating the cluster, so it should already be installed. To access it, run the following command from the same terminal as before:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

⚠️ It is important to run this command from the same terminal as before because, with the first command, we set the context of the terminal to be able to access our Kubernetes cluster in the Civo cloud.⚠️

If you have configured the Kubenconfig correctly, the port-forward command will allow us to access Cyclops's UI from our browser.

To access it, go to https://localhost:3000, and you will be greeted with an empty dashboard. To deploy your application to the cluster, click the "Add module" button in the top right corner. You should be taken to a screen where the first step is to choose a template.

Feel free to use the existing templates or you can import your own (read more about it here). I will use the demo template for this guide as it is the simplest. I name my new module (in the theme of the article) and use the default values for the rest of them. If you want to deploy your own application, use your docker image (with the correct version underneath) in the image field.

To deploy your application, click "Save"!

Cyclops will use the values you specified on the previous screen and, based on the template you used, will create all the necessary resources your application needs. You never had to even look at configuration files! After a couple of seconds ⏳ (depending on the docker image you used in the image field), your application should be up and running.

Now you can access your app with a port-forward command (in a similar way that we access Cyclops), and that’s it ⌛

kubectl port-forward svc/speedrun 3001:80

Time’s Up ⌛

If you followed along, you should have been able to deploy your application to a Kubernetes cluster running in the Civo cloud - in under 10 minutes!

We used the default setup for Civo and for Cyclops. This setup can be vastly improved by using more powerful nodes or adding more of them - all of this can be configured when creating the cluster in the Civo dashboard!

And the demo template that I used in Cyclops is just a simple example of what it can do for you. Play around with other templates and try to make your own. Cyclops was made to quickly and easily create developer platforms that hide the complexities of Kubernetes from developers. It brings the developer experience of big tech to companies of any size.

If you enjoyed this guide, show us your support by starring our repo ⭐

For the past few days, we at Cyclops have been walking between the whiteboard and our laptops, trying to figure out how to design one important part of our project: the authentication of Cyclops to different services. To be more precise, we wanted to allow users to access their private GitHub repos through Cyclops.

Why was this an issue? In the beginning, we were torn between solutions that either bloated the codebase by adding a database that Cyclops would not use apart for the authentication or made the onboarding process overly complicated and scare away potential new users.

After some brainstorming, we found a solution that checked all of our requirements. In this article, I will showcase how Cyclops manages your secrets, the Kubernetes way…

Why did we need to manage secrets?​

A short background about Cyclops so the rest of the article is easier to follow:

Cyclops is a developer-oriented Kubernetes platform. Instead of making your devs learn Helm, Kustomize, or some other Kubernetes configuration manager, Cyclops provides a user interface where they can easily fill in the values to generate needed Kubernetes manifests.

We say it's a platform because you can easily create custom UIs for your Kubernetes workloads (read more about it here). You would store these UIs as templates. You can store templates in several ways, like Helm charts or OCI repositories, but the most popular is probably GitHub repositories.

Cyclops can access templates stored in public repos without issues; provide a repo + path + version, and BAM, you got it. But we wanted to enable Cyclops users to access the templates they stored on their private GitHub repositories (because you rarely make your infra code public).

We knew we could use GitHub tokens as a form of authentication, but how do we securely handle them?

By the way…​

Cyclops is open-source, we would greatly appreciate it if you could support us by giving us a star on our repo ⭐ 🙏

Kubernetes Secrets​

The first issue was storing the GitHub access tokens. Cyclops does not have a database of its own, so implementing one just for storing GitHub tokens seemed like a bad idea. So, we opted to use Kubernetes secrets.

“A Secret is an object that contains a small amount of sensitive data, such as a password, a token, or a key.“ ~ Kubernetes docs

Kubernetes secrets are a great way of storing sensitive data (like tokens) without exposing it in the pod definition or configuration files, so they seemed like a great fit.

However, the second issue was how to use these secrets securely.

Kubernetes Custom Resources (CRDs)​

Let’s quickly discuss custom resource definitions and then we can go on to how we implemented access to private repos.

In Kubernetes, Custom Resource Definitions (CRDs) let you create your own resource types, adding to the default ones Kubernetes provides (pods, deployments, …).

You can define a schema for your custom object with a YAML file and inform Kubernetes. From then on, you can use your custom resource as any other native Kubernetes resource.

Check out our previous blog, where we explore CRDs and use kubectl to gather apples!🍏

kubectl get apples

NAME          AGE
green-apple   6s

How we manage secrets, the Kubernetes way​

Cyclops has a CRD called TemplateAuthRule that allows you to define authorization for specific repositories. The CRD defines which templates you want to authorize and points Cyclops to the authorization data needed for those templates (Kubernetes secrets).

Each time the Cyclops controller fetches a template, it retrieves all TemplateAuthRules from the cluster and tries to match the templates repository to any of the TemplateAuthRules repositories (in the picture below spec.repo). If it does, it will fetch the referenced Kubernetes secrets and apply username and password to authenticate.

In the image above, the Cyclops controller fetches all TemplateAuthRules and tries to match the template repository to spec.repo from a TemplateAuthRule. If it matches, it will fetch the username and password from the referenced secret. In this case, both username and password reference the same secret my-cyclops-secret (spec.username.name and spec.password.name).

To fetch the username secret value, the Cyclops controller will fetch the referenced secret and use the key provided in spec.username.key to get the value from the fetched secret. The same goes for the password.

Since TemplateAuthRulesdoes not store secrets directly, you can still integrate your cluster with the External Secret Operator or other secrets management solutions!

Find a more detailed view into TemplateAuthRules and a tutorial on how to allow access to your own private repos here or by using our CLI here

Any questions?​

Hope I managed to explain how Cyclops manages your GitHub tokens and maybe even given you an idea of how to manage secrets in your own projects.

If you are interested in being a part of the Cyclops community, to contribute with code, content, or even critique, be sure to join our Discord community and leave a star on the repo ⭐ 🙏

Kubernetes applications rarely (if ever) consist of a single resource. In a basic example, you have a deployment running your app and a service to expose its functionality. This requires you to either have one manifest containing the definitions of both the deployment and service or two separate manifests (one for each resource).

Now, imagine you have multiple apps that require multiple manifests to run. To make managing them easier, you will want to group them together in logical units (or packages).

Further, when running microservices, many of these manifests will look very similar, often differing only by a couple of values or lines. As you can imagine, this can quickly become cumbersome to manage.

This is where Helm steps in. While Helm is not new to the scene, in this article, I will show you its benefits and how to improve the Kubernetes experience even further with something a bit newer…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository 🔗. If you like what you see, consider showing your support by giving us a star ⭐

What the Helm ?!​

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

This is a quote directly from the Helm website 🔗, let’s “unpack” what it means…

Package manager​

Helm is often called the package manager for Kubernetes because it allows you to group multiple connected manifests that create an application into a Chart (package), making them easier to maintain.

A chart’s structure looks something like this:

my-chart
├── Chart.yaml
├── values.yaml
├── values.schema.json
└── templates
    ├── deployment.yaml
    └── service.yaml

A chart can contain additional files, but these are the essential ones (for example, a README.md perfectly aligns with Helm's definition of a chart).

The Chart.yaml file could be considered “metadata” of the package, containing some basic information like name, version, maintainers…

In the /templates directory, you will find all the resources that make up your application. All the manifests are grouped here (in this example, it's just a deployment and service).

Instead of using kubectl and applying these resources separately, charts allow you to package them together and install them into your cluster with a single command.

One of the big things that made Helm so popular was the public charts repositories(like ArtifactHub 🔗 or Bitnami 🔗). This allowed people to use complex configurations others made. Many companies publish and maintain helm charts of their own software so people can easily install them in their clusters.

Templating engine​

The second big feature of Helm is the templating engine. In the structure above, you probably noticed the values.yaml file. To understand why it's here, let’s actually look at our deployment.yaml. It can look something like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: {{ .Values.image }}
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
      - image: {{ .Values.image -}}:{{ .Values.version }}
        name: {{ .Values.name }}
        ports:
        - containerPort: 80
          name: http

You will notice it looks a bit different than your normal deployment manifest (like the one you can find on the Kubernetes documentation 🔗).

This is actually a blueprint. Helm allows you to create blueprints with placeholders - {{.Values.image}}. The values for these placeholders are defined in the values.yaml file.

For example, values.yaml might contain:

name: my-app
image: nginx
version: 1.14.2
replicas: 1
service: true

Imagine you have multiple microservices that all use *almost*** the same YAML manifest, apart from a couple of lines or values. For example, they differ only in the image. Helms' templating engine allows you to use the same blueprint for all your microservices and customize the specific details using the values.yaml file.

So, if you have several microservices, you don’t need to write separate YAML files for each one. Just create a template and adjust the values.yaml for each microservice as needed.

The Developer Experience​

While packages and blueprints help when dealing with large manifest files, changing values in such a structure can still be an issue for inexperienced developers. If you look again at the values.yaml file from above, you can easily see how someone can mistakenly type the string “true” instead of boolean true, or even integer 1. It's an honest mistake, but it can cost you hours and hours of debugging time.

That is where values.schema.json comes into play. In this file, Helm lets you define the type of values and their limitations - essentially providing validations for the values.yaml. This makes it harder for developers to make mistakes similar to the ones mentioned above.

But the values.yaml from above is a pretty simple example. You will usually find much larger files with many more values (finding your way here 🔗 will take some time 😅).

And this is where Cyclops 🔗 lets you take the developer experience even further. Cyclops lets you define a UI that hides the complexities of large templates and allows you to define which fields your developers are exposed to.

The screenshot shows the Helm chart I used as an example before but now rendered in Cyclops. You can mold this screen to fit your needs, with many more (or fewer 😊) fields, allowing inexperienced devs to feel confident when deploying their applications in Kubernetes.

And the validations haven’t been lost with Cyclops, far from it → now they are shown instantly.

The great thing about Cyclops is that if you are already familiar with Helm, creating a UI for your use case is quick and simple because Cyclops renders the UI based on the values.schema.json.

To clarify, you can import your own (already existing) Helm charts to be rendered in Cyclops! If you are storing your charts on a private repo, check the documentation 🔗 to see how to connect it securely.

Cyclops is open-source, so give it a go!

Open Source Fiesta​

Helm is one of the most popular ways of handling Kubernetes configurations. It is a graduated project in the CNCF 🔗, maintained by the Helm community 🔗. The project is open-source, and its GitHub repo 🔗 has more than 26K stars and around 670 contributors - a testament to the size of the community around it. e

While Cyclops is a relatively new project compared to Helm, it is following in its footsteps. Cyclops has already been accepted into the CNCF landscape and has a fast-growing community around it.

Hope it helps 🙌​

Thanks for reading the article. I hope you found it useful. If you wish to be a part of the Cyclops community, to contribute with code, content, or even critique, be sure to join our Discord community 🔗 and leave a star on the repo 🔗 ⭐

Command Line Interfaces (CLIs) seem old-fashioned in the age of graphical user interfaces (GUIs) and touchscreens, but they remain essential tools for developers. You may not realize it, but they are used far more often than you might think. For example, if you use git commands over the terminal, you're likely engaging with a CLI on a daily basis.

To give you some background, I work on Cyclops, a tool that provides a graphical user interface for developers to configure and deploy their applications in Kubernetes. Given my employment, why would I, of all people, emphasize the importance of command-line interfaces?

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

Why CLIs 🤔​

Command-line interfaces (CLIs) are incredibly fast for getting things done. They let you perform actions with simple, direct commands, which is especially useful for repetitive tasks. For example, you can search for files or oversee the various programs and services running on your computer with just a few commands. However, this speed is only accessible to those who know the necessary commands.

CLIs also enable fast remote access to machines and servers. Using tools like SSH, you can connect to remote systems from anywhere, allowing you to maintain servers that aren’t physically nearby. Plus, because CLIs are lightweight, they use minimal bandwidth, making remote operations more efficient and reliable.

These are great benefits of having a CLI, but why would Cyclops be interested in developing one? The answer is automation.

Automation and CI/CD ⚙️​

When I talk about automation, I mean writing scripts to handle repetitive tasks, ensuring they are done the same way every time, saving a lot of time. You can automate everything from simple file operations to complex deployments. Automations boost efficiency and reduce the chance of human error since the scripts perform tasks consistently every time they run.

Automation is a standard practice in the software development lifecycle (just think of GitHub actions). If Cyclops had a CLI, it would allow it to integrate into larger systems for deploying applications, like CI/CD pipelines.

You could use Cyclops’s UI to make it easier for developers to configure and deploy their applications in Kubernetes clusters, and a CLI would allow you to automate any part of that process.

For example, once you create a template and publish it on GitHub, GitHub actions could automatically connect the template to your Cyclops instance using our CLI. This would allow your developers instant access to each new template or even any update the template receives. More on automation in future blog posts… 😉

Cyclops CLI - cyctl 🔅​

We didn't want to miss out on the advantages of a CLI, but initially, we struggled to find the time to develop it. However, our community has grown significantly over the past few months, and since we are an open-source project, we began opening issues to kickstart the development of our CLI.

Thanks to our amazing community, we realized that our CLI was closer to realization than we had thought. And just a couple of days ago, Homebrew received a new package - our very own cyctl!

Open Source Magic ✨​

We are very proud to say that cyctl is a community-driven project. While the Cyclops team has been overseeing every change and reviewing every PR, most of the features have been developed by our contributors!

If you're excited about making Kubernetes easier for developers and want to contribute to our CLI or any other part of our project, we’d love to have you on board. Come join us on Discord to connect, collaborate, and be a part of something great!

And if you enjoyed this post, we would be grateful if you could star our repo ⭐ 😊

They say the first step is always the hardest. And when that step is in the direction of Kubernetes, it can feel even more intimidating. You can sometimes feel "paralyzed" by the sheer number of things you don't understand. Or better said, you don’t understand yet.

But once the first step is conquered, the rest feels more attainable. So, let’s take the first step together. Oh, and we'll be using a couple of tools to help us out. After all, we are trying to make this as simple as possible 😉

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

A Cluster 🌐​

The first thing you need to get started with Kubernetes is a cluster. Typically, a cluster represents the pool of servers on which you run your apps. But for now, you don’t need a pool of servers. Let’s start with something simple: a local playground that will help us get the hang of it.

One of the easiest ways to quickly get a cluster running is with Minikube. Minikube is a tool that sets up a local Kubernetes cluster on your computer. It’s perfect for development and testing purposes. To get started, you need to:

1. Install Docker: docker will allow us to run Minikube in an isolated environment, you can find out how to download it here
2. Install Minikube: Follow the instructions on the Minikube site to install it on your machine.
3. Start Minikube: Once installed, you can start your local cluster with the command:

minikube start

This will set up a single-node (single-server) Kubernetes cluster on your machine.

The Configuration 🗄️​

This is usually the trickiest part of working with Kubernetes. For Kubernetes to run your application, you must create a configuration file that tells Kubernetes how to handle your application. These files are traditionally written in YAML and follow their own syntax and rules.

But here’s the good news: Cyclops lets you skip this process entirely.Cyclops is an open-source tool that provides a user-friendly interface for configuring your applications to run in Kubernetes.

The UI that Cyclops provides is highly customizable when it comes to defining your configurations through its templates feature. It also comes with a couple of predefined templates to get you started on your journey.

Cyclops is simple to set up and requires just two commands:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.6.2/install/cyclops-install.yaml &&
kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.6.2/install/demo-templates.yaml

and secondly:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

Just wait a few seconds between these commands to let your Kubernetes cluster start Cyclops.

Now, head over to localhost:3000, and you should be all set!

Running your App inside the Cluster 🏃​

Once inside Cyclops, you’ll be greeted with a screen that says “No Modules Found.” Modules are Cyclops’s way of saying applications. The next step is running your application (module) in the Kubernetes cluster, or in Kubernetes terms, “deploying your application.”

Start by clicking on the Add module button at the top right. This will take you to a new screen where the configuration file from the last step will be generated.

Cyclops uses templates to generate the configuration file (find more about it here). You can create your own, but Cyclops comes with a few predefined templates that are perfect for getting started.

At the top of the screen, choose the demo-template. You’ll notice the screen changes, and new fields appear! Switching to another template will change the fields on the screen, but let’s stick to the demo-template for now.

You can leave the inputs in the fields as they are or change them to your liking, but you must give your module a name!

If you have a Docker image of an application that you created and want to run in Kubernetes, you can do that too! Just put the name of your image in the image field and its version in the version field.

Once you’re satisfied with these fields, click Save at the bottom, and voilà, your application is deployed!

Anatomy of an App 🫀​

One of the challenges with Kubernetes is the variety of resources it uses. However, Cyclops makes it easy by displaying all the resources your modules have created. This visual representation really helps you understand the anatomy of your applications.

With our demo-template and the inputs we entered, we created a simple Kubernetes configuration consisting of a service and deployment, as shown on the screen. These are the two most common resources you will encounter and are a good entry point into the whole system.

The Cyclops interface displays all these components in a clear, organized manner, making it easy to understand how your application is structured and how the different pieces fit together.

For instance, you can see that the application named "my-app" is running on Minikube, with one replica of the Nginx container (version 1.14.2). You can view logs or modify settings right from this interface.

This visual approach helps bridge the gap between developers and Kubernetes' underlying infrastructure, making it easier to manage and understand your applications.

Next steps 👣​

Now that you’ve broken the ice, Kubernetes feels a lot less scary. I suggest you play around with the other templates Cyclops provides and see how different templates create different resources.

The journey to mastering Kubernetes is long and can be tedious. However, you don’t have to walk that path alone! Join our Discord community and connect with others who can help you if you ever feel lost!

If you enjoyed this post, remember to support us by giving us a star on our repo ⭐

When you touch on containerized apps today, Kubernetes usually comes up as their orchestrator. Sure, Kubernetes is great for managing your containers on a fleet of servers and ensuring those are running over time. But today, Kubernetes is more than that.

Kubernetes allows you to extend its functionality with your logic. You can build upon existing mechanisms baked into Kubernetes and build dev tooling like never before - enter Custom Resource Definitions (CRDs).

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

Kubernetes components​

Before diving into CRDs, let's take a step back and look at Kubernetes control plane components, specifically Kubernetes API and its ETCD database. We made a blog on each one of those components previously, so feel free to check it out for more details.

You will likely talk to your Kubernetes cluster using the command-line tool kubectl. This tool allows you to create, read, and delete resources in your Kubernetes clusters. When I say “talk” to a Kubernetes cluster, I mean making requests against the API. Kubernetes API is the only component we, as users, ever interact with.

Each time we create or update a K8s resource, the Kubernetes API stores it in its database — etcd. etcd is a distributed key-value store used to store all of your resource configurations, such as deployments, services, and so on. A neat feature of etcd is that you can subscribe to changes in some keys in the database, which is used by other Kubernetes mechanisms.

What happens when we create a new K8s resource? Let's go through the flow by creating a service. To create it, we need a file called service.yaml

# service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

and apply it to the cluster using kubectl:

kubectl apply -f service.yaml

service/my-service created

kubectl read our file and created a request against the Kubernetes API. API then makes sure our service configuration is valid (e.g., all the necessary fields were there, fields were of the correct types, …) and stores it to etcd. Now etcd can utilize its watch feature mentioned previously and notify controllers about a newly created service.

CRDs and how to create one​

With the basic flow covered, we can now extend it. We can apply the same process of validating, storing, and watching resources to custom objects. To define those objects, we will use Kubernetes’ Custom Resource Definitions (CRD).

CRD can be a YAML file containing the schema of our new object - which fields does our custom object have, and how do we validate them. It will instruct the Kubernetes API on how to handle a new type of resource.

Let’s say your company is in the fruit business, and you are trusted with the task of automating the deployment of apples to your Kubernetes cluster. The example, of course, has nothing to do with a real-life scenario to show that you can extend the Kubernetes API however you see fit.

Apples have a color that can be either green, red, or yellow, and each apple has its weight. Let’s create a YAML to reflect that on our Kubernetes API:

# apple-crd.yaml

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: apples.my-fruit.com
spec:
  group: my-fruit.com
  names:
    kind: Apple
    listKind: ApplesList
    plural: apples
    singular: apple
  scope: Namespaced
  versions:
    - name: v1alpha1
      schema:
        openAPIV3Schema:
          properties:
            apiVersion:
              type: string
            kind:
              type: string
            metadata:
              type: object
            spec:
              properties:
                color:
                  enum:
                    - green
                    - red
                    - yellow
                  type: string
                weightInGrams:
                  type: integer
              type: object
          type: object
      served: true
      storage: true

We defined two properties for version v1alpha1 under .properties.spec:

• color (which can take one of the values in the enum)
• weightInGrams

To tell the Kubernetes API, there is a new type of object, we can just apply the previous file to the cluster:

kubectl apply -f apple-crd.yaml

customresourcedefinition.apiextensions.k8s.io/apples.my-fruit.com created

Kubernetes API is now ready to receive Apples, validate them, and store them to etcd.

Don’t take my word for it, you can create a Kubernetes object that satisfies the schema from the CRD above:

# green-apple.yaml

apiVersion: my-fruit.com/v1alpha1
kind: Apple
metadata:
  name: green-apple
spec:
  color: green
  weightInGrams: 200

and apply it to the cluster:

kubectl apply -f green-apple.yaml

apple.my-fruit.com/green-apple created

Now, your cluster can handle one more type of resource, and you can store and handle your custom data inside the same Kubernetes cluster. This is now a completely valid command:

kubectl get apples

NAME          AGE
green-apple   6s

Can I then use Kubernetes as a database?​

Now that we know we can store any type of object in our Kubernetes database and manage it through the K8s API, we should probably draw a line on how far we want to abuse this concept.

Obviously, your application data (like fruits in the example) would fall into the misuse category when talking about CRDs. You should develop stand-alone APIs with separate databases for such cases.

CRDs are a great fit if you need your objects to be accessible through kubectl and the API to the object is declarative. Also, another great use case for extending the Kubernetes API is when you are implementing the Kubernetes Operator pattern, but more on that in future blog posts 😄

On the other hand, if you decide to go the CRD route, you are very much dependent on how K8s API works with resources, and you can get restricted because of its API groups and namespaces.

Kubernetes CRDs are a powerful tool and can help you build new developer platforms and tools. We at Cyclops develop on top of our CRDs so feel free to check them out on our repository.

Kubernetes has risen to fame over the past couple of years, transforming from a geeky buzzword into a cornerstone of modern software development.

Yet, with its rise to fame, Kubernetes has also become shrouded in myths and misconceptions, which can often deter potential users - “Kubernetes is only for large companies” or “I need microservices for Kubernetes”…

While most of these misconceptions can be said about other container orchestrators, in this article, I focused on Kubernetes as it is the most popular and the first one that comes to mind when people think of container orchestration.

That being said, let’s dive into five of the most common misconceptions about Kubernetes and set the record straight!

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

1. Kubernetes is Only for Large Enterprises​

💨 Misconception: Kubernetes is too complex and resource-intensive for small to medium-sized businesses and is only practical for large enterprises.

🔍  Reality: Kubernetes is highly scalable and can be used by organizations of any size. With managed services like EKS, GKE, and AKS, even small teams can set up and manage Kubernetes clusters. These services take care of much of the heavy lifting, so smaller organizations can easily benefit from the features Kubernetes provides without needing a ton of infrastructure or a big DevOps team.

For example, a startup can easily set up a Kubernetes cluster on AWS using EKS. This takes advantage of AWS’s infrastructure and managed services, making it simpler and more cost-effective to manage.

2. Kubernetes Replaces Docker​

💨 Misconception: Kubernetes is a replacement for Docker.

🔍  Reality: Kubernetes and Docker serve different, yet complementary, purposes. Docker is a platform for containerizing applications, while Kubernetes is an orchestration system for managing those containers across multiple hosts/servers. Docker handles the creation and running of containers, but Kubernetes takes on the orchestration tasks, such as scaling, load balancing, and self-healing.

In practice, Docker containers are often used as the building blocks that Kubernetes orchestrates. For instance, developers use Docker to create container images, which are then deployed and managed by Kubernetes.

3. Kubernetes Manages Everything Automatically​

💨 Misconception: Kubernetes fully automates all aspects of container management without the need for manual intervention.

🔍 Reality: Kubernetes takes care of many tasks like container deployment, scaling, and failover, but it still needs proper setup and ongoing management. You’ll have to configure things like network policies, resource limits, and storage. Plus, keeping an eye on the cluster with regular monitoring and updates is crucial for its health and security.

For example, deploying applications requires configuration files in which you describe declaratively what you want Kubernetes to do with your application. Tools like Cyclops help manage these configurations by providing a user-friendly interface.

4. Kubernetes is Only for Microservices​

💨 Misconception: Kubernetes is not suitable for monolithic applications.

🔍  Reality: While Kubernetes excels at managing microservices, it is equally capable of handling monolithic applications. Kubernetes provides features like horizontal pod autoscaling (HPA), which can be utilized by both microservices and monolithic applications. HPA allows applications to scale based on the load automatically, ensuring your application will not crash under high pressure.

For example, a monolithic application can be containerized and deployed in a Kubernetes cluster. With proper configuration, Kubernetes can manage the application's scaling, deployment, and monitoring just as effectively as it does with microservices.

5. Kubernetes is Too Complex to Learn and Implement​

💨 Misconception: Kubernetes is too complicated for individuals and small teams to learn and implement.

🔍  Reality: While Kubernetes does have a steep learning curve, there are numerous tools, tutorials, and resources available to simplify the learning and implementation process. Platforms like Minikube allow developers to run Kubernetes locally, providing a sandbox environment to experiment and learn.

Online courses, documentation, and community support also significantly contribute to making Kubernetes more accessible. With the right tools, even small teams can effectively use Kubernetes for their projects.

Thanks for reading 🙌​

I hope this article clarified some common myths about Kubernetes. If you enjoyed the read, consider supporting us by giving us a star on our repo!

What started as a frustration with not being able to get in touch with our users, quickly developed into a redesign of the flow of our platform.

My team and I are developing an open-source platform that helps developers deploy and manage their applications in Kubernetes. We have been working hard to expand our user base, and the efforts were starting to show results.

The rising number of installations was satisfying to see. However, that was the only thing we were able to observe. We wanted to know more. We wanted to know what users are doing with our platform and what they are struggling with.

The following short story could be considered a #building-in-public entry of our startup, but I just found it interesting and wanted to share it with you.

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

User Feedback 🗣️​

Since the beginning, we have been trying to talk to our users and gather as much feedback as we can. However, that turned out to be sort of a problem. We knew that people were downloading Cyclops; on our DockerHub, we could see the number of pulled images getting larger by the day.

The problem was that we had no way of contacting our users. We could only see the number of pulls, not who pulled them.

In an attempt to get in touch with our users, we created a Discord server. Discord is a great way to keep your community close to you, and because of it, we have a way of getting to know our users.

So we started talking to them. The feedback wasn’t always constructive…

… but most of it was really positive. However, there is a caveat; a lot of the positive feedback we were getting was from 1-on-1 meetings with our users. In these meetings, we could demonstrate Cyclops's capabilities better than users could on their own. This turned out to be a bigger issue than we thought.

Recently, we implemented telemetry to better understand how our users utilize Cyclops. As soon as the statistics started to come in, boy, were we surprised.

The Problem ❗​

We were really pleased with the number of installations of Cyclops. As it turns out, we were correct in thinking that Cyclops is pretty simple and straightforward to install. But when it came to starting to use it, more than 60% of our users got lost.

So what was the problem?

The thing is, when you want to deploy an application to your Kubernetes cluster, you must provide a template in the form of a Helm chart. We have created a few examples of such charts and published them on our open repository. In all our documentation and blogs, we pointed people toward that repository when starting out with Cyclops. However, it seems that it didn’t catch on. The number of deployed applications was still much lower than the number of started instances of Cyclops.

A Theory 🧑‍🔬​

Here is a fun fact for you, dear reader: the majority of online readers spend less than 15 seconds on a web page (source). Knowing this, could it be that most of our users skimmed over the blogs and documentation and missed out on the reference to our template repository?

We wanted to test this theory. In our last blog, we did another tutorial on Cyclops showcasing its benefits. However, for this specific article, we created a special version of Cyclops. What was so special about this version? We added a default value for the template when creating new modules.

After gathering statistics for some time, the results were in.

The Results 📊​

With a simple change, we saw an improvement in our users' behavior, they no longer got lost at the very first step of using our platform! However, it wasn’t as big of an improvement as we initially hoped for but it was certainly in the right direction. We asked ourselves how to further improve on this issue. And we think we got it 🙌

Since our most recent version (v0.3.0), we have reworked the platform's flow. Choosing a template is no longer an input field but a dropdown. Every instance of Cyclops comes with a couple of premade templates (stored in our templates repository), which you are free to use and abuse. We feel like this will go a long way in showcasing the customizable nature of Cyclops to our users.

But an important part of Cyclops is its ability to use your own templates, and we weren’t ready to compromise on that! That is why we added a new Templates tab where you can add new templates and manage the existing ones. Once added, your new templates will be shown in the dropdown the next time you find yourself deploying an application.

Credits 🦔​

We released v0.3.0 earlier this week, so it is still too early to say how much of an impact it had on our users, but we have high expectations! We might share the statistics once enough time passes, so make sure to follow us to find out!

It would be a shame not to mention PostHog as the telemetry provider we are using, since it turned out to be extremely useful. Because it is hard to find people who will talk with you about your product, gathering statistics gave us a much greater insight into our users.

If you are one of the few readers who gave this article more than the previously mentioned 15 seconds, I hope you found it amusing at least 😁

If you are interested in contributing to our project, whether through coding or providing feedback, join our Discord community and come talk to us!

We perceive things by the way we interact with and understand them. To an infrastructure team, Kubernetes is a great way to scale and manage applications, but for a frontend/backend developer, It may seem complicated and stressful.

Kubernetes introduces many concepts and terminologies (deployments, services, pods…) that take time to grasp and even more time to master. But devs sometimes have to interact with them weekly, if not daily.

Through our experience and research, we identified the three most common ways in which developers engage with Kubernetes.

So, what does Kubernetes look like through the lens of a developer?

Support us 🙏​

Before we start, we would love it if you starred our open-source repository and helped us get our tool in front of other developers ⭐

Touchpoints​

Depending on the structure and development workflow of the company, developers either do not interact with Kubernetes at all because automated processes and scripts are doing it, or they interact with Kubernetes through three touchpoints:

1. 1. configuration files of their application
2. 2. deploying their application in the K8s cluster
3. 3. monitoring their applications

Configuration files​

Configuration files tell Kubernetes how to handle an application. They are declarative, meaning you write the result you want to see rather than the steps to get there.

Most commonly written in YAML, these files are large and complex to read and understand. And being written in YAML comes with its challenges (and quirks) since it is an additional programming language that devs need to learn.

Mistakes in configurations are hard to spot and rectify but are a BIG deal. Even if you coded your app perfectly with no bugs whatsoever (hypothetically 😅), a mistake in the config could mean that your app just won't run.

Deploying​

Deploying your application is the process of starting your app in the Kubernetes cluster. The native way of doing this is with kubectl.

kubectl is the command line tool for Kubernetes. Being a command line tool/interface is something we should take into consideration. Senior devs should be accustomed to CLIs, but junior devs still might be timid. Getting accustomed to kubectl adds a new layer to the learning curve.

However, deploying requires more than knowledge of the available commands of kubectl; it also requires an understanding of the context and how it manipulates Kubernetes objects.

Monitoring​

Now that our devs have configured and deployed their application, they are done, right? Well, no. The application probably has its fair share of bugs and issues, and they are expected to be able to monitor them and fix them when needed.

Finding out what is wrong with your app inside the Kubernetes cluster is not straightforward. Devs need to understand the objects that are in the cluster and how they interact with each other.

For instance, to fetch your app's logs, you need to know that it is run in a Pod. That Pod is located in a Replica Set, which itself is located inside a Deployment. You must understand these relationships while rummaging through your K8s resources with kubectl.

Developer Platforms​

This is just the tip of the iceberg when it comes to Kubernetes. Its complexity drastically elongates onboarding time for new devs, and all the additional steps introduced slow down development cycles.

Companies usually have a dedicated team to deal with infrastructure and Kubernetes. When developers encounter issues or need help, they turn to these teams. But you can imagine that when dealing with something as complex as Kubernetes, needing help is a common occurrence.

This is why we are seeing the rise of developer platforms, which reduce friction between developer and infrastructure teams. A good platform makes the development cycle of creating, updating, and deploying as smooth and straightforward as possible.

Cyclops - Kubernetes platform made for developers​

Cyclops is a fantastic open-source developer tool that abstracts Kubernetes's complexities behind a simple graphical user interface. We call it a platform because your infrastructure teams can customize the UI to suit your specific needs and wants.

So, how does Cyclops solve the issues mentioned above?

1. 1. With Cyclops, your developers never directly interact with configuration files. You create a template, which is then rendered for the developers as a form. This avoids the need to learn languages like YAML and has the added benefit of allowing you to add validations to their input, making it harder for developers to make mistakes.
2. 2. Once the developers have specified what they need with Cyclops' help, deploying their application is as simple as clicking a button.
3. 3. Now that they have deployed their app, Cyclops makes it easy to monitor its state via its user interface. The application's details are easily accessible and include all the resources (and logs) it uses.

Let's see it in action!

The installation is just a two-step process, but there are a few prerequisites, with the main thing being a Kubernetes cluster.

So once you have your cluster up and running, you can install Cyclops with the command below:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/blogs-demo/install/cyclops-install.yaml

And once it's successfully installed (which could take a minute or two), you can access it with:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

Cyclops should now be accessible in your browser at http://localhost:3000.

Now, by clicking on the Add Module button, you will be taken to this screen:

We created a default template for you, but this screen is highly customizable (you can try out your own Helm charts!). Now, instead of reading and writing YAML, developers can fill out these fields by clicking the save button, and their application will be deployed!

This next screen represents the detailed view of your newly deployed application. Here, you can see all the specified resources (and easily access the logs 😉). If anything goes wrong, it will be visible here!

If you wish to change something in the configuration (like adding more replicas of your app), click on the Edit button. You will be taken to a screen similar to the first one, where you can make those changes, again not even knowing that you are dealing with YAML underneath.

Wrapping up​

We hope this article did a good job of showcasing some of the ways developers are struggling with Kubernetes and a potential solution that you could consider next time you or your devs engage with it.

If you are running into issues with Kubernetes or have devs who are pestering you with K8s-related questions, consider supporting us by giving us a star on our GitHub repository ⭐