Git Product home page Git Product logo

kode-operator's Introduction

kode-operator

WARNING! THIS PROJECT IS UNDER HEAVY DEVELOPMENT AND NOT MEANT FOR PRODUCTION USE JUST YET.

Kode-Operator is a Kubernetes operator designed to manage the full lifecycle of various ephemeral and semi ephemeral development environments and tools. It automates the deployment, configuration, and management of Code-server, Webtop, DevContainers, Alnoda, and Jupyter environments within a Kubernetes cluster.

Additionally, it supports authentication and authorization using Envoy Proxy and a standard way for the user to add custom configuration and data.

Description

Kode-Operator streamlines the setup and management of development environments on Kubernetes. By leveraging custom resource definitions (CRDs), it allows users to declaratively specify the desired state of their environments and automates the deployment process.

Whether you need a code server, a web-based development environment, or a data science notebook, Kode-Operator handles the orchestration, ensuring consistency and efficiency.

Key Concepts

Kode

The Kode instance contains a reference to a Kode template. It can also contain other user specific options. For example, a reference to a git repository with vscode settings and extensions.

apiVersion: kode.jacero.io/v1alpha1
kind: Kode
metadata:
  name: my-kode-instance
  namespace: default
spec:
  templateRef:
    kind: KodeTemplate
    name: my-kode-template
  user: myuser
  password: mypassword
  home: /home/myuser
  workspace: my-workspace
  storage:
    accessModes:
      - ReadWriteOnce
    storageClassName: my-storage-class
    resources:
      requests:
        storage: 1Gi

KodeTemplate & KodeClusterTemplate

These are cluster scoped and namespace scoped templates. A template contains an image and some default configuration for that image. You can also include an Envoy Proxy configuration that is then applied to the sidecar of the resulting Kode instance.

Example for KodeTemplate:

apiVersion: kode.jacero.io/v1alpha1
kind: KodeTemplate
metadata:
  name: my-kode-template
  namespace: default
spec:
  type: code-server
  image: linuxserver/code-server:latest
  tz: UTC
  defaultHome: /config
  defaultWorkspace: workspace
  envoyProxyTemplateRef:
    name: my-envoy-proxy-template

Example for KodeClusterTemplate:

apiVersion: kode.jacero.io/v1alpha1
kind: KodeClusterTemplate
metadata:
  name: my-kode-cluster-template
spec:
  type: webtop
  image: linuxserver/webtop:ubuntu-mate
  tz: UTC
  defaultHome: /config
  defaultWorkspace: workspace
  envoyProxyTemplateRef:
    name: my-envoy-proxy-template

EnvoyProxyTemplate & ClusterEnvoyProxyTemplate

These are cluster scoped and namespace scoped template for the Envoy Proxy sidecar. A way to define a standard Envoy Proxy configuration that a Kode template should use. This could be a HTTP filter to an Open Policy Agent (OPA) deployment within the cluster.

Features

  • *Provisioning and update of Code-server.
  • *Provisioning and update of Webtop.
  • Authentication & Authorization support using Envoy Proxy sidecar.
    • OAuth2 With external Oauth2 provider.
    • Basic Auth Use password from Kode.password or Kode.existingSecret.
    • Ext_Authz HTTP and GRPC (Used by for example OPA).
  • Ability to add VSCode Extensions to the KodeTemplate and as a user.
  • Ability to add "preinstalled" software to the KodeTemplate.
  • Include dotfiles and other user settings in the Kode instance.
  • Pause/Prune container on inactivity, keeping the persistent storage.
    • Backup & Restore of user stage. Maybe not feasible.
  • Backup & Restore of user data to S3.
  • A Kode CLI to manage Kode resources

Usage Scenarios

Scenario 1: Setting Up a Code-Server Environment

You want to set up a VSCode-like development environment using Code-server for your team. This setup allows developers to access their development environment from any browser.

1. Create a KodeTemplate for Code-server:

apiVersion: v1alpha1
kind: KodeTemplate
metadata:
  name: code-server-template
spec:
  type: code-server
  image: linuxserver/code-server:latest
  port: 3000
  defaultHome: /config
  defaultWorkspace: workspace

2. Create a Kode Instance Using the Template:

apiVersion: v1alpha1
kind: Kode
metadata:
  name: my-code-server
spec:
  templateRef:
    kind: KodeTemplate
    name: code-server-template
  user: devuser
  password: devpassword
  workspace: my-project

3. Apply the Configuration:

kubectl apply -f code-server-template.yaml
kubectl apply -f my-code-server.yaml

Scenario 2: Using Envoy Proxy for Authentication

You want to secure your Code-server environment using Envoy Proxy with Basic Auth.

1. Create an EnvoyProxyConfig:

apiVersion: v1alpha1
kind: EnvoyProxyClusterConfig
metadata:
  name: basic-auth-proxy
spec:
  auth:
    type: basic-auth

2. Create a KodeTemplate with Envoy Proxy Configuration:

apiVersion: v1alpha1
kind: KodeTemplate
metadata:
  name: secure-code-server-template
spec:
  type: code-server
  image: linuxserver/code-server:latest
  envoyProxyRef:
    kind: EnvoyProxyClusterConfig
    name: basic-auth-proxy
  defaultHome: /config
  defaultWorkspace: workspace

2. Create a Kode Instance Using the Template:

apiVersion: v1alpha1
kind: Kode
metadata:
  name: secure-code-server
spec:
  templateRef:
    kind: KodeTemplate
    name: secure-code-server-template
  user: devuser # Sent to the Envoy Proxy Basic Auth
  password: devpassword # Sent to the Envoy Proxy Basic Auth
  workspace: my-secure-project

3. Apply the Configuration:

kubectl apply -f basic-auth-proxy.yaml
kubectl apply -f secure-code-server-template.yaml
kubectl apply -f secure-code-server.yaml

Install using Kustomize

Kustomize Prerequisites

  • kubectl version v1.28.0+.
  • Access to a Kubernetes v1.28.0+ cluster.

To Deploy on the cluster

TBD

To Uninstall

TBD

Install using Helm

Helm Prerequisites

  • helm version 3.10+.

Helm install

TBD

Helm uninstall

TBD

Contributing

We welcome contributions to the Kode-Operator project! Here are some guidelines to help you get started:

How to Contribute

  1. Fork the Repository: Click the "Fork" button at the top of this repository to create a copy of the repository in your own GitHub account.

  2. Clone Your Fork: Use git clone to clone your forked repository to your local machine.

    git clone https://github.com/<your-username>/kode-operator.git
    cd kode-operator
  3. Create a Branch: Create a new branch for your feature or bugfix.

    git checkout -b feature-or-bugfix-name
  4. Make Changes: Make your changes to the code. Ensure your code follows the project's coding standards and includes appropriate tests.

  5. Commit Your Changes: Commit your changes with a descriptive commit message.

    git add .
    git commit -m "Description of the feature or fix"
  6. Push to Your Fork: Push your changes to your forked repository.

    git push origin feature-or-bugfix-name
  7. Create a Pull Request: Go to the original repository and create a pull request from your fork. Provide a clear and detailed description of your changes and the problem they solve.

Code of Conduct

Please note that this project is released with a Contributor Code of Conduct. By participating in this project, you agree to abide by its terms.

Reporting Issues

If you find a bug or have a feature request, please create an issue in the issue tracker with as much detail as possible. Include steps to reproduce the issue and any relevant logs or screenshots.

Development Setup

  1. Install Dependencies: Ensure you have the required dependencies installed:

    • Go version v1.21.0+
    • Docker version 17.03+
    • kubectl version v1.29.1+
    • Access to a Kubernetes v1.29.1+ cluster
  2. Build the Project: Use make to build the project.

    make build
  3. Run Tests: Ensure all tests pass before submitting your pull request.

    make test

Documentation

If you are adding a new feature, please include relevant documentation updates. Documentation is located in the docs/ directory.

Getting Help

If you need help with the project, feel free to join the discussion forum or reach out on our Slack channel.

Thank you for your interest in contributing to Kode-Operator! Your contributions are greatly appreciated.

License

Copyright 2024.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

kode-operator's People

Contributors

emil-jacero avatar

Watchers

 avatar

kode-operator's Issues

[core] Support webtop

Just like code-server this should be supported.

Webtop is developed and maintained by linuxserver.io. It is a linux desktop in a container.

It will be an ephemeral desktop running in kubernetes. It will be an alternative to a more long lived desktop solution like virtual machines and citrix.

[core] Add support for External-dns

To allow Kode to create an EntryPoint with a subdomain we have two options.

  1. Create DNS wildcard and have fun! This is relatively simple but prevents the administrator from using different gateways or ingresses if needed because the DNS record is pointing to a single IP address.
  2. Use an automated DNS operator like external-dns to manage DNS records. This will ensure that an administrator can deploy multiple entrypoints resources with different ingresses or gatways and IP addresses.

[project] Refactor README

The project

  • Summary: What does it offer?
  • Features: A list of killer features!
  • Link to Project site and documentation

For users

  • How do i use it?
  • How do i submit features requests?
  • How do i submit bug reports?

For developers

  • How do i contribute?
  • How do i setup my environment? ;)

[entrypoint] Able to control Ingress API and Gateway API

A requested feature is to have a CRD that simplifies the publishing of Kode instances.

Each Kode resource should belong to a single user, and only that user. This could be accomplished in many different ways.

Subdomains

Assign a unique subdomain for each user's instance. For example, user1.kode.example.com, user2.kode.example.com.
A sub-path for each Kode instance is required.

Advantages:

  • Clear isolation at the DNS level.
  • Easy to implement with Ingress API or Gateway API.
  • Scales well with a large number of users.
  • Can use wildcard SSL certificates to secure all subdomains.

Disadvantages:

  • Requires DNS configuration to support wildcard subdomains.
  • May have more complex DNS and SSL management.

URL Paths

Use URL paths to differentiate users, such as kode.example.com/user1, kode.example.com/user2.
A sub-path for each Kode instance is required.

Advantages:

  • Easier to manage a single domain.
  • Simpler DNS and SSL certificate management.
  • Also scales well with large number of users.

Disadvantages:

  • Requires careful configuration to ensure no path conflicts.
  • May require more complex routing rules in the Ingress API or Gateway API.
  • Less isolation compared to subdomains.

Unique Ports

Assign a unique port for each user's instance, such as kode.example.com:3001, kode.example.com:3002.
A sub-path for each Kode instance is required.

Advantages:

  • Simple and straightforward implementation.
  • No need for complex DNS configuration.

Disadvantages:

  • Not user-friendly; users have to remember port numbers.
  • Limited number of ports available, not scalable for a large number of users.
  • Might require firewall adjustments.

Summary & Reflection

There are more options like utilizing a service-mesh within Kubernetes to route traffic, but that would require this project to integrate with each service-mesh out there and that would take to much time.

The Unique port option is simple but a bit ugly. I foresee some use-cases where this might be wanted. For example in single cluster deployments, and where there are no easy way to configure DNS and access to certificates.

The Subdomain and URL Paths options are both the standard elsewhere in the industry and are relatively easy to implement.
I might also add support for External-DNS as an option to just using wildcard DNS records.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.