DEV Community: Kubeshop

Monokle 1.8.0 Release Notes

Kubeshop — Mon, 06 Jun 2022 10:56:38 +0000

Team Monokle is proud to announce version 1.8.0 of Monokle by Kubeshop - an open-source desktop tool created to make all things related to Kubernetes manifests and resources simple.

The main features of this release include:
Compare Anything - a cool and useful option created by overhauling the original Diffing Panel
Instant visibility of used images and their metadata
Helm value interactions made easy by hover over pop-up window showing the value of any reference
We also improved the general user experience, largely based on your feedback. Thank you!

Compare Anything - Literally!

Today, we’re relaunching cluster compare as Compare Anything.

While everyone seems to like comparing and deploying local resources to a cluster, we decided to take this a step further to provide optimal visibility for teams deploying at scale.

With Compare Anything, you can do just that! Easily compare resources from different sources across your entire environment with Monokle - a place where you can get the insights you need to manage Kubernetes resources at scale.

Compare Anything allows you to compare any two resource sets including:

Clusters in two separate regions to see how they differ
Helm chart’s standalone and high-availability setups
Production and development Kustomize overlays
Helm and Kustomize Preview to troubleshoot migration

Full visibility of all used images and their metadata

Use the new image tab option from the left menu to list and view all images used across resources
Highlight the images in the editor with the possibility to quickly select any image
Show image ref in the outgoing links pop-over
Refactoring functionality allos you to easily change the image tag across all related resources
Show information about the image from Docker hub

Helm interactions:

Scale usage of Helm templates and handle more cases with our improved highlighting of Values properties in your Helm templates.

Quickly preview the value references while working with Helm templates with our new hover-over feature.
Values file link directly highlights and scrolls to the exact code line containing the property.

Save filter pre-sets for future use

When filtering the resources, you now have the option to save the current filter as a preset in order to load it again at a later time.

UI/UX improvements: Header, Settings, & Shortcuts

We’ve redesigned the header of the application to make it easier to use and understand:

While in local mode

While previewing cluster resources (cluster mode)

While previewing the output of a Helm or Kustomize

We separated the Settings panel into 3 tabs so you can navigate your projects accordingly:

And last but definitely not least, we created a panel showing all keyboard shortcuts so you can work faster and more comfortably.

Other notable fixes & improvements

New keyboard shortcuts:
Ctrl/Cmd + R to reload cluster resources in Cluster Mode
Ctrl/Cmd + Backspace to delete the currently selected file or resource
Filter resources by multiple kinds
As always, you can download the release directly from our website and get in touch to complain or praise the Monokle Team on our Discord Server.

We’re looking forward to hearing from you!

Common Errors Found in Kubernetes Manifests

Kubeshop — Thu, 12 May 2022 12:31:31 +0000

You’ve spent weeks researching Kubernetes and its concepts, from clusters to control planes to pods to ConfigMap. Against all odds, you have finally launched a testing cluster on AWS. As a developer, this is all uncharted territory for you. Because Kubernetes is part of the “new” full-stack your organization has embraced, you need to learn a new way of deploying code.

Eventually, you write the Kubernetes manifest that defines your deployment, type out:

kubectl apply -f /path/to/your-manifest.yaml hit ENTER and…
An error.

Do you know what the error means?

Even if you’ve seen it before or read about it somewhere deep in the Kubernetes docs, how do you go about fixing it? How to adapt to the way your organization deploys on Kubernetes with pre-deployment tools that point out errors long before you spend time running kubectl apply and kubectl logs...

For a while now, we have been building Monokle - an open-source visual tool, a Kubernetes manifest IDE to help YAML experts and newbies alike to edit, debug and manage manifests easier and better.

What is a Kubernetes YAML Manifest?

A Kubernetes manifest is a YAML file that describes each component or resource of your deployment and the state you want your cluster to be in once applied.
Here is an example for a ReplicaSet and three Nginx pods:

`apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: nginx

spec:

selector:

matchLabels:

  app: nginx

template:

metadata:

  labels:

    app: nginx

spec:

  containers:

  - image: nginx

    name: nginx

    ports:

    - containerPort: 8080

Once you’ve created a Deployment, you can always edit your manifest file and re-apply it using kubectl apply… to declare a new state, scale the number of pods, or clean up your cluster.

Where Kubernetes manifests meet Helm and Kustomize

If you’ve spent time in the Kubernetes ecosystem, you’ve probably heard about tools such as Helm and Kustomize. Both extend manifests to improve the developer experience around Kubernetes.

Let’s be clear about what they are:

Helm: A package manager for Kubernetes that uses Charts, which are Go-based templates that ultimately generate YAML-based manifests for deployments.

For example, you can use a simple command like helm install prometheus prometheus-community/prometheus to deploy a functional monitoring agent (and all its requisite resources) on your existing cluster without writing a single line of YAML.

Kustomize: A configuration management tool for customizing Kubernetes objects. With Kustomize, you can take an existing manifest and apply overrides without touching the original YAML file.

While these tools can help avoid some errors, by either delivering community-validated manifests or narrowing the changes you make on existing manifests, unfortunately they don’t help you to validate your manifests, suggest fixes nor to display relationships across the resources.

Why are Kubernetes manifest errors hard to find?

Some manifest-related errors show up right away, like in the scenario that kicked this piece off.

The error: error validating output is a good signal that you need to open your manifest file and look for a syntax error or a missing resource. Others only cause havoc after kubectl apply… exits in a way that implies everything is OK, yet show up as errors later. You can get sucked into the cycle of searching for the different STATUS codes shown by kubectl get pods and reading page after page of Kubernetes documentation for details. That’s because kubectl apply…exits only once your cluster has accepted your deployment, not when the deployment is running error-free with full functionality. You might never know your deployment has failed until you run kubectl get pods or try navigating to your application. Monokle will point out syntax and all kinds of other possible errors and dependencies saving developers time before actual deployments happen.

A few common Kubernetes manifest errors

To help you solve some errors you might already have on your plate, let’s jump into some of the most common, why they happen, and how to solve them.

1. Indentation

As a configuration language, YAML uses maps and arrays to understand how the resources in your manifest are related to one another.

Both lists and maps are defined in YAML using indentation. So, your resources and configurations must be correctly associated.

YAML is quite relaxed with the rules around indentation, not forcing any number of spaces per line, so the important rules are to use spaces and be consistent with indentation throughout your manifests.

2. Maps vs. arrays

In YAML, maps are key-value dictionaries, while arrays are essentially lists, and they have unique syntaxes.

To borrow from our example manifest above, this is a map:

`metadata:

labels:

app: nginx`

And here’s a list:
containers: - image: nginx name: nginx ports: - containerPort: 8080

The difference? Lists are set off by hyphens (-).

Maps are used when there’s a single value for a given key.

Arrays define a list of similar objects, like several containers that should deploy in conjunction.

Often the reasons for using one versus the other in a manifest aren’t clear, and only make sense once you’ve dove into documentation.
‍

3. `invalid type for…` or `got "string", expected "integer"`, aka expected vs. received values

Let's say you need to define the port that a container should expose itself on, and instead of supplying an integer—port: 80—you supply a string—port: "80". Kubernetes won’t know how to handle the wrong type of value, and the error output you receive in return might not be particularly helpful in finding the line responsible.

4. Typos

Hard-to-catch issues, (e.g., starting a manifest with a typelike apiVerion instead of apiVersion), can create error validation errors that often don't help to diagnose the issue.

If you’ve validated your indentation and know you have strings and integers where they should be, check again for spelling or camelCase erros—no YAML validator will be able to find those for you.

5. Invalid references between resources

Manifest will likely reference other resources, such as ConfigMaps, secrets defined elsewhere in the file, or a separate file entirely.
References must be right for a deployment to work. Typos or changed resource labels will often prompt this error if references elsewhere in the manifest(s) haven’t been updated.

6. Invalid output from Helm charts and Kustomize

One downside to these useful tools is that they can abstract away too much, especially for developers who are still getting comfortable with manifests.

For example, when you run Kustomize, it returns a big YAML file or multiple smaller files.

Your only options for double-checking the output are

reading through it with a fine-toothed comb,
running each portion through external validation tools, or
jumping into the deploy-troubleshoot-deploy cycle right away.

The same goes for Helm. It’s a helpful resource for getting started, but because you’re not working on the YAML “by hand,” you don’t know what’s happening inside the files.

So, just because a manifest comes from Helm doesn’t mean it’s error-free or doesn’t need some customization on your part.

Using built-in tools for testing Kubernetes manifest errors

Kubernetes comes with a few methods of simplifying how you identify errors in manifests.

kubectl apply --dry-run: This runs a local dry run that can help catch some glaring errors by printing the object that would be sent but doesn’t give you much information about how the server will apply your manifest. Using --dry-run=server goes one step further by testing your manifest against the server’s state, but it doesn’t persist the resource(s) you’re trying to apply.

kubectl rollout: Follow up kubectl apply... with kubectl rollout status deployment your-app to see the status of your cluster, where it is still waiting, and whether it’s successful, shortening the gap between attempting a rollout and knowing if it’s failed.

Add a rollout to your CI/CD pipeline: You can block your CI pipeline from finishing while you wait for kubectl rollout to exit, and if there’s a non-zero return code, you can fail the task.

Add a readiness/liveness probe: The easiest way to know that a deployment is successful is by pinging your application at an appropriate endpoint and getting a 200 OK response. Kubernetes supports this with simple liveness containers that let you know if your application is running as expected.

*‍While these can help you catch errors a little faster once you’ve started a deployment, they’re still too late.
*

Pre-test for Kubernetes manifest errors with a manifest IDE

So far, we’ve covered the state of manifest testing and some tips on common manifest mistakes.
One problem remains: : How do you make the process of editing and managing manifests more efficient?

The status quo—a cycle of deploying and failing and fixing ad infinitum—means you’re still engineering YAML files, not developing new features for your application and team .

Enter Monokle, an open-source visual tool that simplifies everyday tasks around Kubernetes to help developers be more productive without tedious YAML-engineering. It uses built-in intelligence and syntax checking, giving a comprehensive view of manifests integrity spoting errors before you deployments.

As a result, you can be effective in Kubernetes on day one without looking up a single YAML syntax rule.

Monokle's basic components are:

File Explorer
Monokle’s File Explorer helps you find all your relevant manifest files, which is particularly useful for those complex deployments.

Navigator
The Navigator converts the complex relationships between Kubernetes resources into easily-understood workloads, networks, and access controls and even gives you visual syntax or reference error alerts, including their number and severity.

Editor
And the Editor, which can also switch to a form-fill mode for less YAML-engineering, highlights errors with a detailed explanation and a suggested fix.

Monokle also lets you:

Debug and validate the output of Kustomizations and Helm charts,
View diffs between local and remote resources, and
Navigating between resource relationships and dependencies.

Finishing Up‍

Monokle has everything needed to end a cycle of hunting manifest errors. Download it directly from GitHub or check out our documentation. It’s a desktop application that works on macOS, Linux, and Windows.

We’d love to hear from you. Please join us on Discord!

Tracetest is released. What’s next?

Kubeshop — Tue, 10 May 2022 13:03:23 +0000

We released Tracetest to the public last week. Yay! But what is next?

Our team worked really hard to release the initial MVP version of Tracetest.

Did you hear about our release? In short - Tracetest allows you to utilize the Opentelemetry tracing instrumentation to do deep integration and end-to-end testing…easily. You can read about it in the last blog post, “Introducing Tracetest - Trace-based Testing with OpenTelemetry”.

It was a ‘soft launch’, as the initial release is more of a prototype than a product. We are fans of Marty Cagan’s thoughts about delivering quickly by starting with a Minimal Viable Prototype rather than Product, so we focused on making the first version show the complete flow and enable us to solicit feedback.

In spite of the ‘prototype’ nature, we were blown away by the reception & great comments we received via slack and our Discord channel:

“I'm an OTel maintainer. I saw y'all tweet about this and it looks dope!” -Austin
“I watched https://www.youtube.com/watch?v=WMRicNlaehc and it’s a really cool idea!” -Matt
“We took a look at this in the past day or two and I have to say, we're very interested in this product.” -Dustin

The team was pumped to hear the comments, so we dove back into planning the next major release, which will be a true MVP. Our motto is - We are going to put the ‘Product’ into ‘MVP’. We came up with a simple measure to decide if the tool can be declared a ‘Product’ - we have to be able to test Tracetest’s service with Tracetest. Dogfooding our own product.

With that goal in mind, we compiled a list of the capability we all wanted to add, combined it into a list, filtered it down to a smaller list, conducted a prioritization exercise, and, from that exercise, decided on a core set of capabilities to add. Many of these are ‘meat and potatoes’ - basics the product must have to be functional. Some of the highlights include:

Moving the assertion engine to the backend (Golang) & enabling tests to be run on a CI pipeline.
A full revamp of the UX.
Improving our selector logic that allows spans to be accurately targeted in a non-brittle manner.

As an OSS project, we are developing in public, so you can follow our progress. We have a milestone titled MVProduct with a due date of June 7th, and the team has already dived into the development.

How can you help?

There are a few ways:

1) Tell us how you would like to use the product via our Discord channel, what you would like to see in it, and the direction you would like us to take in the future.

2) Try it out! We have a public demo at demo.tracetest.io. We will be updating it as we code, so it will be getting better and better over the next month as we progress.

3) Talk to us directly. I am available on Discord, on the CNCF or o11y slack (Ken Hamric). I will be looking for teams to talk to about their use case.

In return for your time, I can promise undying gratitude, possibly a shirt in the future (TODO!), and rapid response from the dev team in translating your needs into working code.

Thanks for your interest, and please give us a star on Github!

-Tracetest Team

Monokle 1.7.0 Release — Kubeshop

Kubeshop — Tue, 10 May 2022 12:39:13 +0000

The Monokle Team at Kubeshop is proud to announce version 1.7.0 of Monokle - Manifest IDE, our open-source desktop tool to help you with all-things-related to Kubernetes manifests.
In this release, the main focus was improved manifest validation. We also improved Helm interactions and the general user experience, largely based on your feedback. Thank you!

Open Policy Agent validation

The Monokle team wants to help developers with the tools they need to spend less time fixing and debugging so that they can build the next big feature.
We notice that both startups and enterprises want to comply with best practices and security standards, yet they often meet friction in tooling. Validating your policies in a separate process gets skipped and enforcing it at admission time comes with a poor developer experience.
That’s why Monokle now brings policy validation directly into your editor.
You will no longer need to dive through documentation as help will appear in real-time while editing.

Getting started with policy validation is simple. Open the validation pane at the left and you will see a pre-made list of rules. A big shout out to the DefSec team at Aqua Security as full credit for these rules goes to them. Once you’re familiarized with the rules, enable those relevant to you and that’s it!

Please note that this initial release only works on vanilla Kubernetes manifests and is disabled for Helm and Kustomizations. Let us know what you think about the Open Policy Agent integration and feel free to send us a message when you are missing a rule or are interested in building a plugin with your own set of rules.

Helm

Now you can list the templates under each Chart in the Helm Pane:

Mouse over directive templates to display the location of the Values file associated with.

Cluster workflows

Disable or enable editing resources in cluster mode:

UI/UX Improvements

Pin your favorite projects on the top of the “getting started” page:

First-timer? Don’t worry, we created a tooltip that guides you through the main features:

Other notable fixes and improvements

Fixed the Deploy Resource action on Ubuntu.
Updates: get a hint when to reload Monokle after a new version has been applied
Refreshed the look and feel of the start page
As always you can download the release from our website and get in touch to complain or praise Monokle on our Discord Server - looking forward to hearing from you

Dogfooding Testkube - Part1 - How to Test a Testing Framework

Kubeshop — Wed, 20 Apr 2022 14:04:25 +0000

This post originally published on the Kubeshop blog.

People are fallible. We often need to make decisions based on incomplete information which results in unpredictable behavior. Engineers are often trained to limit those mistakes, but we’re still humans - not robots - and our code is not perfect and can often result in errors.

Engineers (who are also humans - yes - nerds are also humans!) for decades have faced the topic of testing their products. There are numerous tools, frameworks, and techniques for testing code. There are unit testing, functional testing, integration testing, performance testing, stress testing, and many more.

The problem is even trickier when we do things in Kubernetes, which is an “open-source system for automating deployment, scaling, and management of containerized applications.” It handles a lot of the deployment complexity for you but working with it requires a lot of knowledge - and not just for beginners or junior developers, but seniors also need time to become familiar with how everything works.

As Kubernetes is gaining a lot of momentum recently in modern companies, the tooling around it not always is good enough to balance the speed of development and complexity of the platform, so a lot of companies are struggling with in-house tools - they are great to write - but hard to maintain (like any tool).

We, the Testkube engineers at Kubeshop, also want to test our code and the final product, which is a quite small but complicated Kubernetes service with operators, APIs, kubectl plugins, and various other components - everything merges to reduce the complexity of running tests in Kubernetes cluster for the end-user.

ut wait a minute we've just written a testing tool? right? Why not use it to test itself? Yeah!! - we love testing stuff - It could sound like a crazy idea but for example, the Go language (and many other languages) can be compiled by itself, so why not test our testing framework with our testing framework? Also, we’ll get some additional feedback on what to test and how it behaves in a real environment.

Considerations

Now let’s get back a little - that crazy idea needs to be planned to make it real. To test our software we’re using a range of testing techniques, starting with unit testing. In Go and almost all modern languages, it’s quite straightforward: you can use the internal testing library and add some assertion library and you're done.

But it’s only part of the problem - now you can be sure of the quality of the dots (parts of code) in your architectural diagram. What about connections between those dots? That’s the job of integration tests that could be written in a language that other parts are written with - you can take packages and simulate connections between them in the same way as they are orchestrated in real code - but it’s still not the same.

But what to do later? - there is still a lot of complexity that needs to be handled like networking, running Kubernetes plugins, getting results in isolated environments (which Kubernetes is), performance issues (those, fortunately, we don’t have a lot), or other system-related topics.

Some of the above issues can be addressed by End-To-End (e2e) tests which can take part or the whole of the system and test in a semi-production environment simulating real usage. We decided it would be a good fit for Testkube - as some abstraction over testing frameworks and techniques.

Some questions arose during this work - what should be the scheduler for running tests? Should we write some shell scripts or other Github actions manually? What if we want to extend testing suites with different executors? - Probably it would not be flexible. After some ideation sessions, we decided to use Testkube to run our already defined tests against our Testkube clusters, almost all parts were there (like authorizing to cluster with kubectl) so the only missing parts were the installation of the Testkube kubectl plugin and running defined tests.

So we’ve set up our CI pipelines in GitHub and started running tests to test testing tools.

Testing Our Testing Tool

Testkube is cloud-native based on top of Kubernetes. Additionally, we’ve designed it using OpenAPI spec with API-design first in mind. We’ve started by preparing a testing workflow in GitHub which can run Testkube tests - you need only configured access to Kubernetes cluster with kubectl and then install and run Testkube against your tests.

You can find the full Github workflow step for deployment here.

And for starting tests here.

‍‍Starting test suite with valid in-cluster configuration in GitHub workflows.

Test Planning & Execution

To start testing you should need a plan - define what are the critical, most important paths in your service, what is the happy path for them, and how to manage automation of feeding test data (this could be tricky in some old systems without APIs or with complicated access - but if standard testing tools are not enough for you, Testkube will help you here too - simply write your own tests executor).

Next, you’ll need to create Postman tests. Several tips could help you write your tests against services in Kubernetes clusters.

To pass data from outside you can use environment variables in the postman

To feed external data use the -p PARAM=VALUE flag when starting Testkube tests.
You can use the URI variable to use the same test code for testing in different environments (e.g. http://localhost:8080/ on your local machine, and https://my-service.my-namespace:8080/ inside your cluster using internal DNS service) - so it’s almost the same as testing against your local instance of the system.

Yay! We’ve noticed what has been done here - it’s the first time we’ve built foundations for testing Testkube with Testkube (like in the Inception movie)!

Let’s get back to tests - what was the planning/thinking process?

So to start we need to define some tests - we decided to go with API testing first as it feels natural for us (automatic OpenAPI spec validation in Testkube is still in the phase of designing) - and it's the most critical component of our system - and additionally Postman was in place - it allowed us to make quick prototyping on top of our local instances of Testkube API server. It was a good decision to go with design first with OpenAPI spec - testing is really easy with that - just prepare some data, pass them to endpoints and check results - Postman is your tool here! - tests and assertions can be written in javascript. Additionally you have a templating engine in place that can inject Postman internal environment variables everywhere.

We’ve started by writing test suites against our APIs. They can be easily written and run against local development instances. After everything is designed, we could move test code into clusters. With parameterized tests, you can easily write tests on your local development infrastructure and move it into a cluster when you’re ready (I was writing tests against a local go language API server running on my local MacBook).

We’ve created a plan for the “happy path” of our test resource, like creating a new test, running it, and checking if it was run on top of Testkube.Postman has great ability to orchestrate requests and pass data from one to another - we’ve used env variables for that

The environment variables will behave like global variables for a whole Postman test run, you can easily set and get them. We’ve used them extensively to generate random test names and pass created execution ids or execution names.

There were also some assertions with the use of the integrated pm.expect assertions library in Postman.

After the test suite was completed I could simply move it into the cluster with a little effort like defining valid cluster endpoints as we’ve already planned that all URIs will be changed in a valid test run on a cluster with a valid Kubernetes DNS based service address.

If you’re interested in the code of our test, feel free to check it here (just import file as Postman collection) it’s just exported Postman collections JSON file that tests against our Testkube API defined in OpenAPI spec

It was nice that Postman - which we knew how to use (as most of us used it to call APIs for some previous development) - can be run so easily in the Kubernetes cluster.

Everything was run in our GitHub workflows with the use of Actions. The test is run after successful helm chart build and deployment to one of our clusters.

The output of this step is simply Testkube output which can be analyzed in case of a failing build.

Summary

When you’re testing your code in Kubernetes you’re facing a lot of problems, starting from an isolated environment for your service (where calling tests against your services is very limited), and at the end getting results from your test run is not so straightforward. Fortunately, Testkube can help you there, we can manage these (and probably many more in future) issues for you - test engineers should focus only on testing their code.

As our work is not completed yet - just some foundations were built - the next steps will be for sure to extend this testing suite to increase coverage and to test some edge cases or even parallel tests running.

The question always is: was it worthy putting quite a big effort into such tests? - the answer (like for most cases) is only one - YES! For us, 123 failed builds were found already! So it was great to have really fast feedback before our users notice any issues.

Additionally, the second step will be also to test our frontend app - but here we’ll use a different tool for testing React-based applications - look for part 2 of this post ;).

If you’re interested in Testkube you can check out our work on Github, don’t hesitate to say “hello” on our Discord channel - we're a very open community of engineering enthusiasts who are trying to make a change in Kubernetes' world.

If you’re interested in our other projects you can check Kusk (OpenAPI spec powered API gateway) or Monokle (your manifests manager).

This was part 1 of Dogfooding Testkube - please follow our Twitter/Discord to get notifications when part 2 will be ready!

Testing Electron Apps with Playwright

Kubeshop — Wed, 20 Apr 2022 13:49:06 +0000

When projects and teams are just starting out, testing is usually not the main focus. However, as projects grow and get more users more emphasis is placed on testing, in particular, automated testing which can be reused and can be done as part of development tasks.

In this regard Monokle is not that different from other projects or teams, we needed to hit the ground running and just build something, see where it goes and focus on tests later on. Now we’re in a position where we need to make sure that core functionality is not unintentionally affected as new features get added, so having a baseline integration test that runs with our nightly builds makes total sense.

But hey... better late than never and so our story with Electron and integration tests begins.

Monokle is built using Electron which is used to build desktop applications across multiple platforms using a web framework like react. There are multiple testing frameworks out there but very few which are able to run on multiple OS’s and test Electron applications such as Monokle. We decided to use Playwright - as it is both open-source and seems to have Electron support baked in.

Playwright works similarly to other testing frameworks (Selenium, Cypress); it launches the actual application and mimics the actions a user would do, clicking on elements, writing things in text inputs, going through different flows. Assertions are added to make sure the expected results happen in the UI - for example, the opening of a panel or changing a label. Although more time-consuming, launching an application in this way is preferable to running it from source code, since this more closely mimics the end-user experience. There might be small differences.

Let’s dive into the actual tests

Install dependencies

First, we need to install some dependencies:

npm install –save-dev @playwright/test playwright playwright-core xvfb-maybe asar

Playwright is the testing library we are using;
xvfb-maybe is used to run the tests;
asar is used to parse OS packages.

Create configuration file

Create a playwright.config.ts similar to this:



import {PlaywrightTestConfig} from '@playwright/test';

const config: PlaywrightTestConfig = {

 testDir: './<test-directory>',

 timeout: 60000,

 expect: {

   toMatchSnapshot: {threshold: 0.2},

 },

};


export default config;

Write boilerplate

To find parse and run the electron final build we used the functions (findLatestBuild, parseElectronApp) from here.

The credit for these very useful functions goes to Spaceage who made them.

Copy-paste those functions into an electronHelpers.ts file.

In the same file create a startApp function which will be used in our tests to start the actual app.



/**

* Find the latest build and start monokle app for testing

*/

export async function startApp(): Promise<StartAppResponse> {

 // find the latest build in the out directory

 const latestBuild = findLatestBuild();

 // parse the directory and find paths and other info

 const appInfo = parseElectronApp(latestBuild);

 const electronApp = await electron.launch({

   args: [appInfo.main],

   executablePath: appInfo.executable,

   recordVideo: {

     dir: '<recording-path>',

     size: {

       width: 1200,

       height: 800

     },

   },

 });


/**

 // wait for splash-screen to pass

 await electronApp.firstWindow();

 while (electronApp.windows().length === 2) {

   // eslint-disable-next-line no-await-in-loop

   await pause(100);

 }


 const windows = electronApp.windows();

 if (windows.length !== 1) {

   throw new Error('too many windows open');

 }

 const appWindow: Page = windows[0];

 appWindow.on('console', console.log);


/**

 // Capture a screenshot.

 await appWindow.screenshot({

   path: 'screenshots/initial-screen.png'

 });


 return {appWindow, appInfo, electronApp};

}

In the end, the electronHelpers.ts should look something like this:



export async function startApp(): Promise<StartAppResponse> {

  ...

}


export async function findLatestBuild() {

  ...

}


export async function parseElectronApp() {

  ...

}

Writing actual tests



import {Page} from 'playwright';

import {test} from '@playwright/test';

import {ElectronApplication} from 'playwright-core';

import {ElectronAppInfo, startApp} from './electronHelpers';


let appWindow: Page;

let appInfo: ElectronAppInfo;

let electronApp: ElectronApplication;


test.beforeAll(async () => {

 const startAppResponse = await startApp();

 appWindow = startAppResponse.appWindow;

 appInfo = startAppResponse.appInfo;

 electronApp = startAppResponse.electronApp;

});


test('test click', async () => {

 // Click button.

 await appWindow.click('text=Click me');

// Exit app.

 await electronApp.close();

});


test.afterAll(async () => {

 await appWindow.screenshot({path: 'screenshots/final-screen.png'});

 await appWindow.context().close();

 await appWindow.close();

});

The code snippet above can give a pretty good idea of what can be done with an Electron app which is very similar to testing a website. Also, there is extensive documentation on the playwright website on how to: access elements, click, fill in text input and other values, scroll, and so on.

To execute the tests add a script to your package.json file with this command: xvfb-maybe npx playwright test - and run it with “npm run <script name>”

Using Models for UI Tests

One thing which is not Electron specific but it comes with the Playwright library is using models: https://playwright.dev/docs/test-pom.

Structuring your code around these models will result in: code reusability, lighter tests in terms of code written, and an easier understanding of what a test is supposed to do.

POMs can also help when some UI refactoring comes knocking at the door because the code is structured in a more versatile way.

An example of how a model would look like:



import {Locator, Page} from 'playwright';


export class TestModal {


 private _page: Page;


 private readonly _okButton: Locator;


 constructor(page: Page) {

   this._page = page;


   this._okButton = page.locator('#button-identifier');

 }


 async clickSave() {

   await this._okButton.click();

 }


}

‍

Mocking/Handing OS file selections or different actions between IPCRenderer<>IPCMain

My time using Playwright was really nice until we had to automate a file selection flow, which seems very simple: open a file or a folder from the computer.

This sounds like a breeze. It was difficult to find any documentation on how to do this in a straightforward way.

The way we’re opening file selection windows is using dialog.showSaveDialogSync from the Electron framework and Playwright is not able to click on that window since it is native and not created within the Electron app environment.

To automate opening a specific file or folder in our tests we had to add a new handler for that specific event, but IPC channels cannot be overwritten and they can have only one listener. So we did the following:

Inject some code in the app which will have a different channel when the app is in automation mode;
Start the app with an automation flag only in testing(this leaves the app usable for other use cases);
In tests use the same channel name as when we started the application and override the handler. ```

const name = 'some name';

const chanel = 'select-file-automation';

await electronApp.evaluate(({ ipcMain }, params) => {

ipcMain.handle(params.chanel, () => {

return [params.name];

});

}, { chanel, name });


Using this logic we are able to easily test OS-specific functionalities such as working with folders and files which are crucial for a code editor such as Monokle.

#Automate on GitHub
To get the most of our tests, we’ve added them in our nightly builds so we can see if we’ve broken anything during the day. The reason for not adding them to run on every commit was that it takes ~20 minutes for everything to run, which would have led to extended waiting times in our development cycle.

We have set up Playwright to take screenshots and record videos, these files can be accessed from the Github actions as well to get a real-time view of how the tests are working or failing.

Go to: the action => click on it => click on summary => click on output.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/273w3eduea7xpfarjl74.png)

Below is a snippet for running Electron tests as part of Github actions. We have a complete flow [here](https://github.com/kubeshop/monokle/blob/main/.github/workflows/monokle-ui-tests.yml).

on:

push:

branches:

test-branch

workflow_dispatch:

jobs:

ui-tests-mac:

runs-on: macOS-latest

steps:

... prepare for tests, install &build

name: E2E Test for Electron 🧪

run: npm run ui-test

name: Upload Test Results 🗃

if: always()

uses: actions/upload-artifact@v2

with:

path: test-output/**

ui-tests-windows:

runs-on: windows-latest

steps:

... prepare for tests, install &build

name: E2E Test for Electron 🧪

run: npm run ui-test

name: Upload Test Results 🗃

if: always()

uses: actions/upload-artifact@v2

with:

path: test-output/**


#Future steps
As the Monokle project grows so will our end to end testing, here are a few steps we plan to add in the near future:

Breakout the logic from the [electronHelpers.ts](https://github.com/kubeshop/monokle/blob/main/tests/electronHelpers.ts) file into an npm library which can be maintained and reused independently of our projects;
Breakout specific [antd](https://ant.design/docs/react/customize-theme) logic(modal, tree, pane) models into a library which can be reused for testing by other people;
Expand the tests we have for the general functionality of Monokle.
A complete example of our working tests and how to run them can be found on the Monokle open source repo [here](https://github.com/kubeshop/monokle/tree/main/tests) and in the corresponding [documentation](https://github.com/kubeshop/monokle/blob/main/docs/testing.md).

As always you can download the release from [GitHub](https://github.com/kubeshop/monokle) and get in touch to complain or praise Monokle on our [Discord Server](https://discord.gg/uNuhy6GDyn) - looking forward to hearing from you!

Monokle 101 - Managing Your Kubernetes Manifests

Kubeshop — Wed, 20 Apr 2022 13:35:53 +0000

This post originally published on the Kubeshop blog.

Managing Kubernetes manifests can be a difficult, time consuming task if you don’t have an easy way to manage them at scale. That is, if you don’t have Monokle.

Monokle is an open source desktop tool that takes the grunt work out of working with your Kubernetes manifests, it gives you a high-level view of their contained resources and relationships with the options to edit, refactor, preview, diff, and navigate before deploying them to your clusters.

And you don’t need more than a working knowledge of YAML to do it.

Monokle’s user interface includes a smörgåsbord (this writer is Swedish...) of components to help you work with your manifests;

A resource navigator to help you navigate your resources
Intelligent source and form editors for your resource YAMLs
Dedicated views and preview functionality for Kustomize and Helm Charts
Cluster view and compare functionality
Templates to help you get started with new resources

And so much more!

Getting Started

Upon installing and opening Monokle, you might begin by opening an existing folder containing any number of manifest files. Monokle’s UI is built to help you easily visualize their contained resources and relationships between them.

With a simple hover of your cursor you can visualize incoming links and outgoing links to your resources, clicking into any of these links will navigate you to the target resource.

Monokle validates all resource links it finds and indicates to the user whether there is an error - making it easy to find - and fix - any invalid links in your set of resources.

Beyond links, if you make changes to names, references, or any other line items within your resources source, Monokle will immediately alert you if anything you do is inconsistent with the required syntax or schema.

If you’re not fluent in YAML most resources will have a form-based editor allowing you to make changes to any value in a simple and easy-to-understand format. Those changes are reflected within the source code as you work.

Working with Kustomize

Monokle has built-in support for Kustomize - allowing you to see all customizations and patch files detected in your folders:

An extremely powerful functionality is the possibility to preview a kustomization; Monokle will run Kustomize and show you all the resources that were generated by Kustomize in the resource navigator - including links, errors and warnings for each resource. You can easily update the kustomization and update your preview to interactively debug and validate the output created by Kustomize before you deploy these to your cluster.

Working with Helm Charts

Monokle offers a similar function for Helm - allowing you to visualize your Helm charts and their values files:

Just like for Kustomize you can preview a Helm Chart which will run Helm in the background and show you the generated resources in the resource navigator:

You can interactively make changes to your values file and recreate the preview at any time, allowing you to validate the output of Helm before applying it to your cluster.

Connecting to Clusters

Not only does Monokle allow you to work with local manifest files - it also allows you to explore and work with resources in your cluster - including all the link and content validation available for local resources.

Since the number of resources in your cluster can be overwhelming, Monokle allows you to filter your resources through different criteria via the central Navigator column.

Another useful tool when working with a cluster is the Diff functionality - allowing you to both compare individual resources to those in your cluster - or you can compare an entire set of resources to see how they differ from those already deployed in your cluster.

In either case, you can easily deploy your local resources after diffing - or replace your local resources with those in your cluster instead.

Creating Resources

While much of the above has been focused on existing resources either locally or in your cluster, Monokle has a number of features to help you create new resources from scratch, including a library of templates that can help you quickly get up and running with simple Kubernetes objects:

Using a template will prompt you for basic information required to generate the corresponding resources and will result in ready-to-deploy resources that can be deployed to your cluster(s) without any further modifications.

You’re just getting started!

We’ve just scratched the surface of all the functionality provided by Monokle to make your everyday manifest-related tasks easier - check out our documentation to see what else you can do - or download Monokle from GitHub and join our Discord community to ask questions and suggest improvements.

Thank you!

TestKube: A New Approach to Cloud Native Testing

Kubeshop — Wed, 20 Apr 2022 13:25:02 +0000

This post was originally published on the New Stack.

When companies talk about modernizing their tech stack or removing legacy infrastructure, it often includes everything except their testing toolchain — they are just happy when it isn’t broken.

While almost everything from simple web apps to stateful databases have moved toward more cloud native architectures, the way we test our applications is frequently still firmly stuck in another era.

It’s not without reason: Testing is usually tightly integrated with development tooling and related workflows because running them as part of builds allows us to easily check that the built artifacts are working as they should. However, this also creates a tightly coupled stack that is brittle to change and not resilient in the face of failure.

Cloud native is all about making things more modular, reusable and loosely coupled, yet a tightly coupled testing toolchain is the antithesis of these ideals. Being tied to certain tools and related workflows limits testing modularity across single tests, entire workflows and disparate infrastructures.

When only a small bug fix or functionality is added, integrated CI/CD workflows often force you to rerun your entire test suite, even when only a single test run may be needed. Once you have a workflow set up, what you are allowed to do as a tester is often limited by your CI/CD tooling and the access you’re given. And it’s often up to you to cobble together a coherent test-result dashboard based on the tools used to build and test your applications. Finally, once you have built your testing workflow for one cluster or platform, it is probably easier to start fresh again rather than try to port it elsewhere and even keeping it relevant for your current infrastructure can be a challenge.

Making Testing Cloud Native

Just putting testing on a cloud native platform like Kubernetes won’t help that much either. Provisioning test environments is also somewhat easier, especially with a GitOps approach, but grappling with different environments, cluster networking, remote access and so forth is still a challenge. And unfortunately, many testing tools aren’t “made for k8s,” which can result in clunky approaches when using them to test applications running on Kubernetes.

To help overcome these challenges and bring testing into the cloud native era, a few things are necessary. First, making your pipelines more reusable and modular to be used in any CI/CD or testing framework allows you to quickly adapt to changes in your solution without the need to adapt or create a completely different pipeline that is tightly coupled to the CI/CD or testing framework. Secondly, tests should be aware of the state of your infrastructure and integrated into it. By making testing cloud native, we can all bring code to production faster and more confidently.

Testing on Kubernetes for the Cloud Native Era

Building off the insights above, we’ve created TestKube, an open source lightweight testing framework for Kubernetes that takes a somewhat opinionated approach to testing.

1. Tests are included in the state of your cluster.

Tests are defined and executed using Kubernetes constructs and services in the cluster itself, ensuring that your applications and services are always “testable,” instead of having to rely on correctly configured, externally available tools and artifacts at any time. Test execution is performed from within the cluster itself, removing the need to configure/open your Kubernetes network for the sake of test execution, and no external dependencies are needed to validate that things are working as they should.

Test execution can be triggered by both internal and external triggers — kubectl commands, Kubernetes resource updates, or by CI/CD systems interacting directly with the TestKube API server. Need to rerun a single test to validate a ConfigMap update? No problem! Or run the entire test suite after your application has been deployed, triggered by ArgoCD? TestKube has you covered.

2. Test workflows and results are modular.

Test scripts, orchestrations and executors follow a generic format that is possible to use/implement for any type of test — functional, performance, security, conformance, etc. Test results are aggregated in a common format and exposed to external tooling via APIs or as standard metrics that can be consumed by tools like Prometheus, Grafana and such. This modularity allows teams to repurpose and reuse tests as needed and moves away from being tied to the abilities of a single CI/CD tool for test-related activities on Kubernetes.

3. Testing is environment aware and integrated.

The underlying architecture is open and modular. Since native Kubernetes constructs, like custom resources and ConfigMaps, are used to configure and orchestrate tests, GitOps workflows and tooling can ensure that tests in your cluster are always up to date. QA engineers can focus on building the right tests for your applications without having to worry about how or when to deploy them into your cluster or environment for execution, while they still have the power to both run tests and analyze test results as needed.

Where We Are and Where We Are Going

Given the ambitious goals set out above, Testkube is definitely a work in progress but already in a state to deliver on several of them. We’ve started with supporting the execution of Postman Collections for APIs and Cypress tests for UIs, and we plan to support more types of scripts, including Selenium, K6, JMeter, SoapUI and Cucumber. Check out the latest 0.8.0 release to see how you can orchestrate multiple scripts into complex integration tests and get integrated results via TestKube’s test result dashboard.

From YAML Engineer to YAML Herder

Kubeshop — Wed, 20 Apr 2022 13:16:04 +0000

_This post originally published on the New Stack.
_
A common trope in the Kubernetes world is that you are not a DevOps engineer or site reliability engineer, but rather a YAML engineer. Everywhere you look, there is another YAML manifest to be wrangled.

Creating, editing, updating, and applying these manifests is the daily grind of the YAML engineer. Tools for inspecting and understanding objects in a cluster are good and plenty, but integrated tools for pre-deployment tasks related to creating, editing, validating and debugging manifests is scarce. As the size and complexity of these manifests grows, trying to manage boilerplate code and finding small differences between your current context and the production cluster you are trying to fix comes close to being impossible. Hours can be spent hunting down trivial mistakes, and those hours are not cheap. Your entire team — or business! — can be blocked while an elusive YAML-indentation holds your production environment hostage.

Attempting to manage YAML files by hand is moving us away from the DevOps ideal of infrastructure as cattle and toward infrastructure as pets. Nurturing each fat-finger mistake or CVE update back to health is a painstaking process. YAML engineers are veterinarians, nursing each individual YAML pet back to health.

There has to be a better way to manage manifests and turn YAML engineers into herders of YAML cattle.

From Cloud Native DevX to OpX

Looking across the aisle to the cloud native developer, we see a totally different world. Modern integrated development environments, like Github Codespaces and Gitpod, are all about accelerating the “inner loop” for the developer, so they can focus on writing code rather than wrangling details. With cloud-based IDEs, even helping a colleague or reviewing code becomes a click away.

Ephemeral dev environments don’t make you lose your current context. Just open a new workspace with their environment, make your edits or comments, and switch back to your work. Being able to describe this process in code reaps many benefits, from reducing configuration drift to creating many possibilities for automation.

We need to find a way to translate the advantage of the cloud native developer experience (DevX) into better operations experience (OpX). YAML engineers do not have the same number of choices to accelerate their inner loop. Code editors will have some support, either natively or via plugins (which probably don’t work well together) or they can choose to use yet another CLI (yech 🤮). What is really needed is a “manifest IDE” that helps with all of these tasks in a well-integrated and consistent way, creating the cloud native OpX.

Monokle: Bringing OpX to Cloud Native

Monokle is your open source YAML IDE to bring real OpX to the cloud native world. Monokle makes it easy to manage and debug YAML manifests before you deploy them to your cluster.

To begin with, Monokle helps you quickly get a high-level view of your manifests, along with their contained resources and relationships. It allows you to visualize and navigate resources both within and outside your cluster, and diff them against any changes you want to make. It validates references between resources to ensure you haven’t misspelled an object name or namespace, and lets you fix those interactively to make sure your changes are getting the job done.

Once you understand how your manifests work and work together, Monokle lets you easily edit resources without having to learn or look up YAML syntax. You can refactor manifests while still maintaining the integrity of names and references throughout all of them. Finally, if you are using kustomize or Helm, you can preview and debug the resources they generate; validate their links, values, etc. You can even compare a set of generated resources to those already running in your cluster, all to ensure that when you hit the “deploy” button, all will go as smoothly as you had promised in the pre-release meeting.

Monokle brings OpX to YAML engineers who want to turn their YAML manifests into cattle, rather than having to treat them like pets.

Monokle sits squarely between traditional developer IDEs and operational cluster dashboards. IDEs are great at managing individual manifests, but generally fail to give the “big picture” when it comes to providing a manifest-centric view of defined resources and their relationships and related workflows. Cluster dashboards, on the other hand, generally don’t provide any functionality for working with manifests. They are all about inspecting and managing resources already running in your cluster and do not focus on pre-deployment artifacts or workflows.

Monokle fills this gap by providing a holistic view of your Kubernetes manifests and focusing directly on related workflows — editing, validation, debugging, diffing, deploying, etc. Monokle works nicely together with both IDEs and cluster dashboards, complementing them with manifest-centric functionality and workflows.

Getting Started with Monokle

Monokle is in its open source infancy; there are so many directions it could take, problems to solve and users to make happy! Ultimately though, it’s about making life easier for the people managing manifests. If you are looking to improve your cloud native OpX, give Monokle a try. Download it or build from GitHub, and let us know what we can do to make you a happier YAML engineer.

Can You GitOps Your APIs?

Kubeshop — Wed, 20 Apr 2022 13:09:09 +0000

This post originally published on The New Stack

The management of large-scale infrastructure is increasingly turning toward GitOps and Infrastructure as Code. In the classic pets-vs.-cattle analogy (sorry to the vegans), these techniques allow you to easily replicate and replace infrastructure when things go wrong, dramatically reducing the cost and complexity of management.

In addition, they become a single source of truth to understand the current state of your infrastructure and what has changed.

At the same time, just like “Software is eating the world,” APIs are eating software. OK, maybe not eating, but certainly powering.

They are everywhere and have become the standard way to expose functionality. However, the way we currently create and build our APIs does not always match our best practices for running infrastructure.

Code-First vs. Design-First APIs

A code-first approach to APIs is a more traditional approach. Developers receive business requirements and code the API, leaving the formal documentation until later, or most commonly, not at all. Platform teams will be blocked until the initial release then be required to do a lot of manual testing to make sure everything is configured correctly.

On the other hand, in a design-first approach to API development, APIs are first defined then coded. This definition provides clear and unambiguous documentation and acts as the “source of truth” for all aspects of the team’s development from frontend to backend to microservices, similar to the way Git becomes your source of truth in GitOps. Design-first APIs create a common understanding of both functional and non-functional aspects of your software’s behavior. In a nutshell, it answers the question: “What can I make this API do?”

Designing Your APIs

The OpenAPI specification has become ubiquitous in the modern world of developing APIs because it is a simple and standard way to describe and document your APIs. In addition, one major benefit of OpenAPI is that it is machine-readable. Based on the content of your OpenAPI definition, software can be written that interacts with your API. For example, Swagger UI provides a nice user interface where developers can test and become familiar with your API and OpenAPIGenerator can generate clients and servers from your OpenAPI definition.

Once defined, this definition can drive a multitude of downstream activities, including generating stubs to ensure developers adhere to the API, creating mocks to enable testing, building and integrating documentation, and constructing deployment artifacts. These tasks can often be done in parallel and in an automated fashion.

State of APIs in Kubernetes

Currently, to expose your API in Kubernetes, ingress resources need to be written and you will need an ingress controller, often referred to as an API gateway, to update the state of the cluster to allow traffic to reach your applications and services. Traditional ingress controllers can be hard to learn and manage and even when you do, it is a manual process. For every ingress controller you use, you need to learn their feature set, resource format(s) and configuration attributes. Some ingress controllers have their configuration spread across multiple Kubernetes resources, making it difficult to get a full picture of the application’s configuration. This issue is made worse when you factor in quality-of-service configurations, such as timeouts and retries, which can be their own resources.

Therefore, to successfully deploy their APIs to Kubernetes, developers or their DevOps teammates currently need to spend their time learning new Kubernetes resource formats and keeping those up to date as their API evolves, rather than actually designing and implementing their APIs. And their DevOps engineers need to worry about developers tampering with meticulously crafted Helm charts rather than just writing their APIs!

Kubernetes needs a “single pane of glass” source of truth of the app’s configuration and how the API works to bring it into the GitOps era.

Bringing GitOps to Your Kubernetes APIs With OpenAPI and Kusk

The OpenAPI specification gives us the ability to declaratively define APIs. It also already contains most of the information we need for an ingress configuration, is extensible via extension annotations, and given the ubiquity of OpenAPI, many API developers are comfortable with this format. Using OpenAPI as a source of truth reduces repetition by bringing information already in your OpenAPI specification into ingress resources. It also eliminates the need to learn how to write ingress resources.

Enter Kusk and Kusk Gateway, an open source attempt to fill that gap in the OpenAPI-Kubernetes toolchain.

(overly simplified Kusk workflow)
These are the basics of Kusk Gateway.

Kusk (Swedish for coachman) automates the generation of ingress resources for various popular ingress controllers by treating your OpenAPI specification as the source of truth for their configuration. Kusk currently supports generating configurations for Ambassador, Traefik, Linkerd and Nginx-Ingress. And thanks to an x-kusk OpenAPI extension, API developers can add Kubernetes and QoS-related metadata to their OpenAPI definition, which Kusk will automatically transform to ingress-controller-specific configurations, including things like:

CORS configuration
Timeouts
Mapping transformations
Namespace/service configuration
Rate-limiting
more to come (security, etc.)

Platform teams can feed Kusk the API’s specification and have ingress resources ready to go and up to date with any changes being made to the API. And just like with GitOps, this can be automated as part of the CI/CD pipeline, meaning no manual editing and fewer errors.

While Kusk helps you adopt an OpenAPI-first approach to API development with an existing ingress controller, it doesn’t really allow you to tap into the full potential of your OpenAPI definition, which is why the Kusk project also includes a dedicated ingress controller that uses OpenAPI as its primary source of configuration: Kusk Gateway. Using Kusk Gateway as the ingress controller, API developers and DevOps engineers can use an OpenAPI definition directly to configure the exposure of their APIs — no intermediate configuration generation necessary!

The Kusk Gateway approach to OpenAPI-first development provides a number of benefits:

Engineers don’t have to learn new configuration format(s) and create corresponding configurations for deploying APIs on Kubernetes.
The OpenAPI definition becomes the source of truth for both functional and QoS/deployment aspects of an API instead of this information being managed in separate configuration files.
Developers can rapidly iterate on their API without having to require platform team resources. Kusk Gateway will automatically (re)configure itself as the OpenAPI definition evolves.
Developers don’t have to write boilerplate code that Kusk Gateway can provide out of the box based on the OpenAPI definition, for example:
Request-validation — Kusk Gateway can automatically validate incoming requests against an OpenAPI definition and provide API consumers with helpful error messages, providing a better user experience and eliminating the need for developers to write this logic themselves.
Mocking — Kusk Gateway can automatically provide mocks and sandboxes for exposed APIs, helping API consumers simulate different scenarios while they are integrating with an API without burdening the underlying API with these requests.

Under the hood, Kusk Gateway is powered by Envoy Proxy, a battle-tested, and production-ready proxy that routes traffic to services defined in your OpenAPI specification.

Wrapping Up

If you’re adopting a design-first approach for your APIs (which you should be!) and are moving into Kubernetes, Kusk enables you to:

Adopt an iterative OpenAPI-first development workflow for APIs under Kubernetes.
Harness all the greatness of an OpenAPI definition in your API deployment.
Integrate OpenAPI-first with both traditional and GitOps-based deployment workflows.
Give Kusk or Kusk Gateway a try and let us know if it does (or doesn’t) help your developers and/or platform engineers improve their everyday API development workflows.

Check out the GitHub repo and full documentation to learn more about Kusk and Kusk Gateway and download their latest releases. Leave a star on the repo to stay updated on new features and improvements, and join our Discord community to connect with others and get in touch with the Kusk team on any issues or suggestions you might have. We’re looking forward to it!

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Ambassador Labs.

An OpenAPI-first Ingress Controller for Kubernetes - Kusk Gateway

Kubeshop — Thu, 14 Apr 2022 17:44:26 +0000

Introduction

The OpenAPI specification has become ubiquitous in the modern world of developing APIs. It is a great way to describe and document your API.

A major benefit of OpenAPI is that it is machine-readable; i.e. software can be written that can “do stuff” based on the content of your OpenAPI definition.

Take, for example, SwaggerUI which provides a nice user-interface where developers can test and become familiar with your API, or openapi-generator that can generate clients and servers from your OpenAPI definition.

What if we took advantage of the machine readability of OpenAPI and had a machine configure your Kubernetes cluster for your API, based on the contents of its OpenAPI definition?

Current state of the world

Currently, to expose your API in Kubernetes, you need to write Ingress resources. Ingress is made up of routing rules that define how and where traffic is forwarded to your services, or a contract, if you will. In addition to your Ingress resources, you need an ingress controller to update the state of the cluster to allow traffic to reach your applications based on your ingress configuration

The problem with traditional ingress controllers is that they can be hard to learn and manage. Each has their own feature-set and uses their own resource formats that need to be learned. This is a difficult hurdle for those just starting out with Kubernetes.

Another issue that we contend with is getting a full picture of our application configuration. Ingress configurations, like it or not, are part of it. Some Ingress controllers may have parts of their configuration spread across multiple resources, meaning that all of them have to be fetched. This issue is made worse when you factor in quality of service configuration, such as timeouts and retries which could also be their own resources.

What about in a microservice architecture? A single OpenAPI specification describes an API that could be made of multiple microservices. However the ingress configuration requires dedicated Kubernetes resources.

Instead a better way would be to have a ‘single pane of glass’ view of the app’s configuration.

The OpenAPI specification itself is the perfect way to achieve this. OpenAPI already contains most of the information that you must specify in an Ingress configuration. OpenAPI is extensibile via extension annotations and given the ubiquity of OpenAPI, we can be confident in saying that API developers are comfortable with this format.

We at Kubeshop believe that OpenAPI should be enough to configure your application’s ingress. This prevents repeating yourself by redefining information already in your OpenAPI specification in Ingress resources. This also prevents needing to learn how to write Ingress resources

The Kusk solution - an Ingress Controller that understands OpenAPI.

We decided to address these issues by creating an Ingress controller that understands OpenAPI - Kusk Gateway.

All of the configuration you would keep in Ingress resources can now be kept in a single place (your OpenAPI definition), providing that single pane of glass configuration for your API thanks to our x-kusk extension.

Under the hood, Kusk Gateway is powered by Envoy Proxy, a battle-tested, and production-ready proxy that routes traffic to services defined in your OpenAPI specification.

This approach provides a number of benefits;

You don’t have to learn new configuration format(s) and create corresponding configurations for deploying your API under Kubernetes
Your OpenAPI definition becomes the source-of-truth for both functional and QoS/deployment aspects of your API - instead of this information being spread out over multiple files
You can rapidly iterate on your API without having to require DevOps resources - Kusk gateway will automatically (re)configure itself as the OpenAPI definition evolves with each iteration
You don’t have to write boilerplate code that Kusk Gateway can provide out-of-the-box based on the OpenAPI definition: request-validation, mocking, metrics/analytics, security, etc.
And something that benefits you that we would love to hear about.

Kusk Gateway Alpha is now available on GitHub. Despite being in alpha, has quite a lot of things going for it:

Automatically configure routing to your APIs using your OpenAPI definition

By embedding your OpenAPI spec in a Kusk Gateway API Custom Resource, applying it just like any other Kubernetes resource is all that’s required to fully configure routing to your API.

For more information, read our official API resource documentation

Configure Quality of Service and CORS settings from within OpenAPI

Using our supported annotation you can configure quality of service settings such as retries and timeouts as well as configuring CORS within your OpenAPI specification.

For more information, read our official CORS documentation

Support for routing to static resources such as CSS and Javascript

To facilitate the serving of static content with your APIs we have a custom resource for routing to these also.

For more information, read our official static resource documentation

Closing Remarks

We dare to say that the alpha release of Kusk Gateway is mature and stable enough for local development and evaluation. As we close gaps and add more features over the coming weeks (hopefully based on your feedback) we aim to release a production-ready version early next year.

Configuring and enjoying the powerful benefits of Ingress in Kubernetes shouldn’t be as cumbersome as it can be. Let Kusk Gateway do the heavy lifting for you so you can focus on what matters: your application!

If Kusk Gateway has piqued your interest, we would love to hear your feedback either in the form of an issue on Github (linked below) or a direct message on our Discord Server (also linked below) and if you would like to help us evolve Kusk Gateway, we accept all contributions with open arms, whether that be documentation improvements, a bug fix, or even whole features.

Check out the Github repo and full documentation to learn more about Kusk Gateway and download the alpha.

Leave a star on the repo to stay updated on new features and improvements.

Join our Discord community to connect with others and get support!

DEV Community: Kubeshop

Monokle 1.8.0 Release Notes

Compare Anything - Literally!

Full visibility of all used images and their metadata

Helm interactions:

Save filter pre-sets for future use

UI/UX improvements: Header, Settings, & Shortcuts

Other notable fixes & improvements

Common Errors Found in Kubernetes Manifests

What is a Kubernetes YAML Manifest?

Where Kubernetes manifests meet Helm and Kustomize

Why are Kubernetes manifest errors hard to find?

A few common Kubernetes manifest errors

1. Indentation

2. Maps vs. arrays

3. invalid type for… or got "string", expected "integer", aka expected vs. received values

4. Typos

5. Invalid references between resources

6. Invalid output from Helm charts and Kustomize

Using built-in tools for testing Kubernetes manifest errors

Pre-test for Kubernetes manifest errors with a manifest IDE

Monokle's basic components are:

Finishing Up‍

Tracetest is released. What’s next?

How can you help?

Monokle 1.7.0 Release — Kubeshop

Open Policy Agent validation

Helm

Cluster workflows

UI/UX Improvements

Other notable fixes and improvements

Dogfooding Testkube - Part1 - How to Test a Testing Framework

Considerations

Testing Our Testing Tool

Test Planning & Execution

Summary

Testing Electron Apps with Playwright

Let’s dive into the actual tests

Install dependencies

Create configuration file

Write boilerplate

Writing actual tests

Using Models for UI Tests

Mocking/Handing OS file selections or different actions between IPCRenderer<>IPCMain

Monokle 101 - Managing Your Kubernetes Manifests

Getting Started

Working with Kustomize

Working with Helm Charts

Connecting to Clusters

Creating Resources

You’re just getting started!

TestKube: A New Approach to Cloud Native Testing

Making Testing Cloud Native

Testing on Kubernetes for the Cloud Native Era

Where We Are and Where We Are Going

From YAML Engineer to YAML Herder

From Cloud Native DevX to OpX

Monokle: Bringing OpX to Cloud Native

Getting Started with Monokle

Links

Can You GitOps Your APIs?

Code-First vs. Design-First APIs

Designing Your APIs

State of APIs in Kubernetes

Bringing GitOps to Your Kubernetes APIs With OpenAPI and Kusk

Wrapping Up

An OpenAPI-first Ingress Controller for Kubernetes - Kusk Gateway

Introduction

Current state of the world

The Kusk solution - an Ingress Controller that understands OpenAPI.

Closing Remarks

3. `invalid type for…` or `got "string", expected "integer"`, aka expected vs. received values