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 ⭐

Have you ever thought of contributing to open source? If you are here, you probably did 😄

For a beginner, it might seem confusing, and I can relate - I've been there myself. However, you found the willpower to push onwards and learn more about this process and I hope this article will show you that it is not as complicated as it may seem.

Most repositories that are accepting contributions usually have a CONTRIBUTING.MD file that you should look out for. Since not all repositories are the same, this file will tell you more about the process of contributing to that specific repository.

However, some general rules can be applied to most repositories, and we will go over them in this article.

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 ⭐

Where to contribute?​

The first question that comes to mind is: Where to contribute?

Well, you should start with the projects you are already using. Maybe some library needs updating, or some tool has a bug?

You may want to contribute to some project within your domain of expertise or a project that uses the tech stack you are comfortable with.

These are great contenders, and you should look into them.

If you don't know any projects but still want to contribute, browse on GitHub or go to sites like Quine, where many open-source repositories are looking for contributors.

For this article, we will use our open-source repository - Cyclops.

How to know what needs improving?​

Whether you are looking for something to do or already know of a bug that needs fixing, all contributions start in the same place - the Issues tab.

If you are new to the project, you can look for the “good first issue” label that most repositories have. As the name suggests, they are a good entry point to get involved in a project. All of the issues should have a description of the problem.

If you know of a problem or bug that is not listed here or you want to see a new feature get introduced, open a new issue! Once you open the issue, the maintainers will decide what to do next, and you should wait for their response before you start coding.

Pro Tip: If you are opening a bug issue, be sure to write down the steps on how to reproduce the bug!

How to contribute?​

Okay, we found a repo, an issue we want to work on, talked with the maintainers, and were given the green light to work on the issue. Let's finally start coding!

1. Fork the repo​

The first step is forking the repository. This will make a copy of the project and add it to your GitHub account.

2. Clone the repo​

Now go to your repositories and find the forked repo. Click on the < > Code button and select one of the options (HTTPS / SSH / GitHub CLI).

Copy the content in the box. Now open your terminal and position yourself where you want to save the project locally. Once you have positioned yourself, type the following command in your terminal:

git clone <paste the copied content>

After a few moments, you should have the project locally on your PC!

3. Create a new branch​

Now, go to your local folder and create a new branch. Be sure to check out the CONTRIBUTE.md of the project to see if the maintainers want you to follow some rules for the naming of branches!

4. Commit and push your changes​

Once you have your branch ready, you can start changing the codebase. After you finish, commit your changes and push them to your forked repository. Be sure to follow the commit message conventions if the repository has them in place (check the CONTRIBUTING.md).

5. Open a pull request​

Now that you have pushed your changes and want to merge them to the main repository, it is time to create a pull request! Once again, you should check the CONTRIBUTING.md rules to see if the maintainers would like you to stick to a naming convention when creating PRs and what they like to see in the description.

❗Be sure to set the base repository to the original repository you forked from❗

I created a PR, now what?​

You are satisfied with your changes and successfully created a pull request to the main repository. What now? Now, you wait.

Depending on the urgency of the problem your PR is fixing and the schedule of the maintainers, you will have to wait for somebody to review your pull request. Be prepared to explain why and what you did (if you didn't do a good job in the PR description) and to make changes if necessary.

Don't take any requests for changes personally. All of you are here for the betterment of the project and nobody is ill-willed. If you disagree with the opinions of the reviewers, tell them! A healthy discussion has never been a bad thing.

Why fork? 🍴​

You are probably wondering why we had to fork the repository at all. Why not just clone the original and work on a separate branch? Basically, remove the #1 step and isn't the rest the same?

Well, you could try, but once you push your changes, you will realize you don't have the authorization to do so! By forking the repo, you become the owner of the copied repository with the rights to change the codebase. This is a neat system to ensure only the changes approved by the original maintainers go through.

Go contribute!​

Now that you are armed with this information, you are ready to go and make your mark in the open-source world! Go help the myriad of projects you have and haven't heard of, and join this growing community. Your help will be greatly appreciated, I'm sure of it 😉

If you have been in the open-source community lately, you know what I am talking about. The story goes something like this: There were loads of videos/blogs/events hyping up open-source contributions, mainly as a good gateway to land your dream software engineering job. And to some extent, it is true.

However, this trend has also brought a flood of pull requests (PRs) that contribute little to nothing or, worse, add clutter to the codebase.

And this is why, lately, you can find a wave of blogs and videos on the theme of “Why you should NOT contribute to Open-Source.”

This article will show how bad it can get with the latest surge of unsavory PRs.

Support us​

Before we start, we would love it if you starred our open-source repository and help us get our tool in front of other developers ⭐
(The irony is not lost on us here... 😄)

ExpressJS​

The latest drama has happened in the epxressjs GitHub repo. As you can see, there were loads of “Update Readme.md” pull requests.

This doesn’t immediately sound bad; perhaps the Readme was riddled with typos? It's a long shot, but let's investigate. Unfortunately, that wasn’t the case. Looking closely at some of these PRs, we will see the drama's root cause.

So let us take a look…

Maybe it’s just one bad apple? Well, let’s look at some others…

As you can see, these PRs are not trying to better the project they contribute to. Although somewhat comedic, having lots and lots of such PRs is a nightmare for the project's maintainers.

And the last one, I think, tells the bigger picture in this story. It seems that lots of these PRs were a learning experience (assuming “Collage” was a mistype of “College”). Although, that is an assumption made in good faith.

Some of them could have been done as a sort of shortcut for bolstering resumes, which is a far more alarming intent.

The missing puzzle piece​

Newcomers don’t understand that contributing is not all about the code. It is about investing your time in understanding the project and the issues it is trying to solve, being a part of the community and the discussion, and wanting to better the project because you want it to thrive.

And that is what is praised about open source contributions, the will to learn and the will to help. In the process, you demonstrate that you can be proactive and solve complex issues. That is what employers are really looking for.

One look at contributions like these, and you can be sure that you will be ignored by potential employers.

Final thoughts​

Now, there were some external actors in the latest PR nightmare that I won’t be naming here because I doubt that they acted with ill intent. It’s the latest buzz, and I am sure that you can find them with a single Google search if you wanted to.

It’s important to mention that when considering contributing to open-source, start by looking at the projects you already use and are familiar with.

Alternatively, focus on projects where you have domain expertise, as sharing that knowledge can be a valuable resource for the maintainers.

Have you had any bad experiences contributing to open-source?