Developing for Kubernetes with Okteto

Jul 19, 2021

In this last article in this series on developing cloud-native apps for Kubernetes, we're taking a look at another popular developer solution, Okteto. Just like Tilt and Garden, Okteto is the product of a small, cloud-native startup with the same name. The company is based in San Francisco, backed by venture capital, with an engineering team led from Madrid in Spain. In fact, Okteto is a Kubernetes play on the Spanish word for 'byte'.

Okteto provides a very similar experience to its contemporaries, providing software developers with the ability to code and run their applications in a Kubernetes cluster. Where Okteto differs in its approach, is its relative simplicity in terms of developer experience, and its predilection for deployment to remote Kubernetes clusters. Let's deal with the remote cluster approach first.

Remote Clusters

Just about all of the tools that focus on developing apps using Kubernetes seek to remove complexity from the developer, so that she can focus on the inner loop. But, if you're running a Kubernetes cluster on a laptop, that doesn't entirely remove that complexity. Yes, Docker Desktop, Minikube, Kind, k3d et al are all designed for just such a scenario, but it's still Kubernetes. And Kubernetes is still difficult to understand if all you're interested in is shipping a new code feature.

Whilst other tools are reasonably ambivalent when it comes to local or remote clusters, Okteto's focus is on development against a remote cluster. It's this idea of removing complexity for the developer that informs this approach. And to achieve this goal, Okteto offers two approaches for developing against remote clusters; a freemium model on Okteto Cloud, and a self-hosted solution called Okteto Enterprise. This doesn't prevent a developer from using Okteto (which is open source) with a local Kubernetes cluster, but a lot of the value in Okteto is delivered through Okteto Cloud and Okteto Enterprise. Before we describe what that value is, let's get an overview of how Okteto works.

The Basics

Okteto works from a manifest that describes the application deployment and its environment, which is YAML-based, and is generally called okteto.yml. The manifest is a declarative description of the application running on Kubernetes for development purposes. It contains items such as the deployment name, the image used to derive a development container, the ports to forward, volume definitions which associate container paths with persistent volumes, and much more. A rudimentary definition of a manifest can be created using the Okteto CLI; running okteto init causes Okteto to examine the working directory for hints about the application (e.g. Java with Maven, Python, JavaScript). It populates the manifest with an appropriate development image for the language in question, as well as defining source code directories for syncing, volumes for caching packages and artefacts, and ports for exposing services and debugging. Here's a simple example:

name: api
image: okteto/maven:latest
command: bash
workdir: /okteto
  - /root/.m2
  - .:/okteto
  - 5005:5005
    cpu: "2"
    memory: 4Gi

With a suitable manifest defined, an okteto up command establishes a development container running in the cluster, either from scratch, or by replacing the original deployed application. Once up and running, Okteto starts up a local bidirectional syncing service for the defined source directories using Syncthing. And, it also injects a small SSH server inside the running container to enable integration with IDEs, such as Visual Studio Code. The command specified in the manifest is executed inside the development container (which could be a shell), and thereafter inner loop development can begin. Any source code changes are automatically synced to the development container, and the developer can build, run or test those changes from within the container.

Okteto Cloud

As already mentioned, Okteto is big on the idea of remote clusters, especially that provided by it's Okteto Cloud service (running atop GKE). So, what does Okteto Cloud provide that might tempt a developer to choose a remote cluster against which to code their application?


The first benefit is the simplicity that a managed environment provides. If you're a developer, you don't necessarily want to acquire the skills of a Certified Kubernetes Administrator, just to provide the environment in which to develop. Okteto Cloud takes that complexity away by providing developers with dedicated namespaces within a multi-tenanted environment. Those namespaces are locked down to avoid compromise, of course, but a lot of organizations might elect to choose Okteto Enterprise instead, which provides the same experience on self-hosted infrastructure.


Normally, namespaces are private to the user that owns them, but it's also possible to share namespaces with teammates. This is not a unique feature, of course, as it's also available in the commercial offerings of some of the other tools we've lifted the lid on in this series. It is, however, an important feature.


It's safe to say that developers love to visualize things, and Okteto Cloud provides great insight into what's running in the namespaces that your using through its UI. It provides information on the running applications (with the ability to place a deployment in development mode, exposes logs down to container granularity, and generates secure endpoints for consuming the application (if appropriate). Because Okteto Cloud is a multi-tenanted environment, service definitions of type NodePort and LoadBalancer are ignored, and are translated into ingress rules managed by Okteto Cloud, instead. It's even possible to bring your own ingress for situations where vanilla ingress rules won't suffice.

The ability to visualize your development environment is very useful, but for anyone who prefers the command line, Okteto also has a fully-featured CLI to augment what can be achieved through the UI.


As well as giving the developer a means for developing an application in a container on Kubernetes, Okteto also provides a pipeline mechanism for deploying applications. This is especially useful as a prelude to developing an application service using Okteto. The pipeline can deploy from a Git repository, and is governed by a separate manifest and schema. The manifest is defined in a file called okteto-pipeline.yml, and might look something like this:

  - okteto build -t${OKTETO_GIT_COMMIT} frontend
  - okteto build -t${OKTETO_GIT_COMMIT} api
  - cd k8s && kustomize edit set image${OKTETO_GIT_COMMIT}
  - cd k8s && kustomize edit set image${OKTETO_GIT_COMMIT}
  - kubectl apply -k k8s
  - frontend/okteto.yml
  - api/okteto.yml

The schema is very compact at present, with the main focus on the deploy key, which allows for the definition of multiple commands to execute in sequence.


Inevitably, there's more! Okteto can work with an extended implementation of the compose syntax (called stacks) for those developers who find the Kubernetes API too cumbersome, and facilitates integration with CI/CD workflows with some ready-made GitHub Actions. It also has a neat live preview feature for testing the changes submitted in a pull request (PR) in an ephemeral environment associated with the PR.

Okteto has many, if not all, of the main features of its competitors. What may make it stand out for some, is the focus on simplicity, giving the developer the freedom to concentrate on the task of coding. Developing on Kubernetes is never going to be zero-touch, but Okteto does a good job of abstracting the complexities, and even goes the extra mile for developers who prefer less verbose declarative configuration, with its stack schema.

If you're using Okteto to develop your cloud-native applications, we'd love to hear about your experiences, and how you think they compare with similar tools.

You May Also Like

These Stories on Tech

Feb 1, 2024
Dec 15, 2022
Sep 14, 2022