kuberise/kuberise.io

kuberise.io

kuberise.io is a free open source internal developer platform for Kubernetes environment. The goal is to provide tools and templates in Kubernetes environment by a fast and easy installation to help developers focus on the development of the business applications rather than installation and configuration of side tools and preparations of the environments and automation.

Prerequisites

• CLI tools: kubectl, helm, htpasswd, git, openssl
• A Github account or another git repository system
• K9s for dashboard (recommended)
• A kind kubernetes cluster for local installation (kind create cluster) or any other kubernetes cluster
• cloud-provider-kind for loadBalancer services and ingresses in kind cluster.

Installation

1. Fork this repository https://github.com/kuberise/kuberise.io into your Github account.
2. Clone your new repository in your local computer and enter to the folder.
3. Run this command:

./scripts/install.sh [CONTEXT] [NAME] [REPO_URL] [REVISION] [DOMAIN] [TOKEN]

• [CONTEXT] This is your kubernetes context. You can find your current kubernetes context by running this command: kubectl config current-context
• [NAME] This is the name of your platform. For this name there should be a values-[NAME].yaml in app-of-apps folder and also a [NAME] folder in values folder for all configurations.
• [REPO_URL] This is the url of your forked repository.
• [REVISION] This is the branch or commit sha or tag of the commit that you want to use for this installation. For example you can write "main" to deploy from the main branch.
• [DOMAIN] This is the domain for the cluster. All platform services and applications would be subdomain of this domain, for example: keycloak.[DOMAIN]. If you are deploying into minikube you can choose minikube.kuberise.dev for the domain then your keycloak address would be keycloak.minikube.kuberise.dev
• [TOKEN] If you are pushing this code to a private repository, you have to put a token here so the ArgoCD can access your repository. If your repository is public, skip this parameter.

Example: If you deployed a kubernetes cluster using minikube start and your platform name is local-example then this would be the installation command:

./scripts/install.sh minikube local-example https://github.com/kuberise/kuberise.git main minikube.kuberise.dev

For more information please read documentations here: kuberise.io

kuberise.io's Issues

ArgoCD Sync Issues

Title: Fix ArgoCD Sync Issues with MutatingWebhookConfiguration and ValidatingWebhookConfiguration in EKS

Description:

We are experiencing significant sync issues with ArgoCD in our EKS environment due to the presence of MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources. These issues cause several tools to become out of sync, affecting the stability and reliability of our deployments.

Environment:

• Platform: EKS
• Tool: ArgoCD

Steps to Reproduce:

1. Deploy resources including MutatingWebhookConfiguration and ValidatingWebhookConfiguration using ArgoCD in an EKS cluster.
2. Observe the synchronization status in ArgoCD.
3. Notice that several tools become out of sync.

Expected Behavior:
ArgoCD should be able to manage MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources without causing sync issues for other tools.

Actual Behavior:
The presence of MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources results in several tools becoming out of sync in ArgoCD.

Possible Solution:
We need to investigate and implement a solution that ensures ArgoCD can handle these webhook configurations correctly. Potential approaches might include:

• Configuring ArgoCD to ignore certain webhook configurations if they are managed externally.
• Modifying the synchronization logic to better handle these resource types.
• Documenting any required configuration or setup steps for ArgoCD and EKS to avoid these issues.

CPU and Memory Requirements for Kuberise Tools

Title: Define CPU and Memory Requirements for Kuberise Tools

Description:

To optimize the deployment of Kuberise in a Kubernetes cluster, it is essential to understand the resource requirements of each tool included in Kuberise. This will help in accurate resource allocation and ensure smooth functioning without over- or under-provisioning the cluster.

Task:

Create a detailed table listing each tool in Kuberise along with their CPU and memory requirements.

Steps to Complete:

1. Identify Tools: List all tools and components that are part of the Kuberise platform.
2. Resource Measurement:
   • Deploy each tool individually in a controlled environment.
   • Measure the CPU and memory usage under typical load conditions.
   • Record the peak and average usage.
3. Document Findings: Create a table documenting the resource requirements for each tool.

Table Structure:

Tool Name	CPU (Average)	CPU (Peak)	Memory (Average)	Memory (Peak)
Tool 1	X millicores	Y millicores	A MiB	B MiB
Tool 2	...	...	...	...
...	...	...	...	...

Additional Information:

• Ensure the measurements are consistent and taken under similar conditions for all tools.
• Consider including a buffer in the resource recommendations to account for variability in workloads.
• Document any assumptions made during the measurement process.

Acceptance Criteria:

• A comprehensive table is created listing each tool in Kuberise with its CPU and memory requirements.
• Documentation of the methodology used to measure the resource usage.
• Recommendations for resource allocation based on the findings.

Post installation steps

After installing kuberise.io, having some post installation steps related to either setting up DNS for the exposed LB using cloud-provider (for local), or running nip.io. Also, adding example URLs for all scenarios would be helpful. Finally, adding the credentials of the applications (Argo, Grafana, Keycloak, etc.) also helps.

Ingress should work in Kind

ingress-nginx-controller is using LoadBalancer. In minikube this is handled well therefore it's working.

But in Kind, probably there's no default ingress controller, so we should use MetalLB to fix the behavior when used in Kind.

Deploy kuberise.io to AKS

Deploy kuberise.io to AKS

Description:
We need to deploy kuberise.io, to Azure Kubernetes Service (AKS) cluster. This will help our users who would like to work with kuberise.io in AKS.

Kuberise Bot

Title: Automate Training and Updating of kuberiseBot with Latest Repository Changes

Description

This issue outlines the steps to automate the training and updating of a custom GPT-based bot, named kuberiseBot, using GitHub Actions. The bot will be trained with information from our open-source project and docs repositories (kuberise.io and kuberise.github.io) and the documentation website (https://kuberise.io). The goal is to ensure that kuberiseBot always has the latest information to assist with questions about installation, configuration, and architecture for new features.

Steps to Implement

1. Create a Training Script:

   • Develop a script that can pull the latest data from the kuberise.io and kuberise.github.io repositories.
   • Extract documentation from the Markdown files in the kuberise.github.io repository.
   • Format the extracted data for training the GPT model.

2. Set Up GitHub Actions Workflow:

   • Create a GitHub Actions workflow that triggers on every push to the main branch of both repositories.
   • The workflow should:
     • Clone the repositories.
     • Run the training script to prepare the data.
     • Trigger the training process for the GPT model with the prepared data.

3. Train the GPT Model:

   • Use a cloud-based service (such as OpenAI, AWS, or Google Cloud) to train the GPT model with the latest data.
   • Ensure that the trained model is updated with the new information from the repositories.

4. Deploy the Updated Model:

   • Once the training is complete, deploy the updated GPT model.
   • Ensure that kuberiseBot uses the latest model to answer queries.

5. Integration with GitHub Actions:

   • Add steps in the GitHub Actions workflow to automatically deploy the updated model after training.
   • Set up environment variables and secrets in GitHub Actions for secure access to the cloud service used for training and deployment.

Example GitHub Actions Workflow

name: Update kuberiseBot

on:
  push:
    branches:
      - main
    paths:
      - 'kuberise.io/**'
      - 'kuberise.github.io/**'

jobs:
  update-bot:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kuberise.io repository
        uses: actions/checkout@v2
        with:
          repository: 'kuberise/kuberise.io'
          path: 'kuberise.io'

      - name: Checkout kuberise.github.io repository
        uses: actions/checkout@v2
        with:
          repository: 'kuberise/kuberise.github.io'
          path: 'kuberise.github.io'

      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.8'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r kuberise.io/requirements.txt

      - name: Run training script
        run: |
          python kuberise.io/scripts/train_bot.py

      - name: Deploy updated model
        run: |
          python kuberise.io/scripts/deploy_bot.py
        env:
          CLOUD_API_KEY: ${{ secrets.CLOUD_API_KEY }}
          CLOUD_API_SECRET: ${{ secrets.CLOUD_API_SECRET }}

Additional Notes

• Ensure that the training and deployment scripts are robust and handle errors gracefully.
• Consider setting up notifications for the team when the bot is updated.
• Test the entire workflow in a staging environment before deploying to production.

Resources

• GitHub Actions Documentation
• OpenAI API Documentation

By following the steps outlined above, we can automate the training and updating process for kuberiseBot, ensuring it always has the latest information from our repositories and documentation.

AWS Load Balancer Controller

I would like to enable the AWS Load Balancer Controller so the services ingress can have a public dns and ip address.

Azure COSI Driver for Kubernetes

Title: Integrate Azure COSI Driver for Kubernetes

Description:

We need to integrate the Azure COSI Driver for Kubernetes into Kuberise. This integration will enable the use of Azure storage services through the Container Object Storage Interface (COSI) within our internal developer platform, providing seamless and efficient storage solutions for developers.

Tasks:

1. Research and Documentation:

   • Review the Azure COSI Driver documentation to understand its requirements and functionalities.
   • Identify the prerequisites and dependencies for integrating the driver into a Kubernetes environment.

2. Integration Development:

   • Develop a Helm chart or Kubernetes manifests for deploying the Azure COSI Driver within Kuberise.
   • Ensure compatibility with existing Kuberise components and configurations.
   • Implement necessary configuration options to allow customization for different environments.

3. Testing:

   • Create test cases to verify the integration of the Azure COSI Driver.
   • Deploy the driver in a staging environment and run the test cases to ensure proper functionality.
   • Address any issues or bugs identified during testing.

4. Documentation:

   • Document the integration process, including installation steps, configuration options, and troubleshooting tips.
   • Update the Kuberise documentation to include information about the Azure COSI Driver integration.

5. Release:

   • Prepare the integration for release by creating appropriate versioning and tagging.
   • Announce the new feature to the Kuberise community and provide guidance on how to use the Azure COSI Driver with Kuberise.

Acceptance Criteria:

• The Azure COSI Driver is successfully integrated into Kuberise.
• Comprehensive documentation is available for users to follow and implement the driver.
• All test cases pass, confirming the reliability and stability of the integration.
• Users can leverage Azure storage services through Kuberise without additional manual configurations.

Additional Context:

The Azure COSI Driver enables Kubernetes clusters to interact with Azure storage services, providing a standardized interface for object storage management. Integrating this driver into Kuberise aligns with our goal of offering versatile and cloud-agnostic storage solutions for developers.

References:

• Azure COSI Driver for Kubernetes GitHub Repository
• COSI Specification

pgAdmin Integration

I would like to add pgAdmin service for developers to be able to explore the database inside the cluster.

Acceptance Criteria:

• I can enable pgAdmin installation in values yaml file.
• I can open and login to pgAdmin
• I can connect to postgresql database from pgAdmin and explore the cluster

Kuberise DNS domain input parameter

Title: Add DNS domain input parameter to install.sh script

Description:
The install.sh script should be able to accept a DNS domain for the Kubernetes cluster as an input parameter. This will allow users to specify the DNS domain directly when running the script, and not copy pasting dns domain in all ingress configuration of all platform tools and microservices.

Expected Behavior:
The install.sh script should:

1. Accept a DNS domain as an input parameter.
2. Use the provided DNS domain in the configuration and setup of the Kubernetes cluster.

Tasks:

1. Modify the install.sh script to accept dns-domain parameter.
2. Validate the input DNS domain for proper format.
3. Update the script to use the provided DNS domain in the Kubernetes cluster setup.
4. Use the dns domain in all ingress settings of all tools and microservices.
5. Update the documentation to reflect this new input parameter.

Specify scopes necessary for token (private repository)

When running the install.sh script, a token must be specified if a private Github repository is used. It would be very helpful if scopes required to run Kuberise could be specified.

Enable SSO for pgAdmin

I would like to enable sso for pgAdmin, so pgAdmin has the option to login using keycloak. It should use the realm "Platform" from keycloak and not the master realm.

Integrate Minio

I would like to integrate minio as a platform service to the kuberise

K8sGPT

Title: Integrate K8sGPT into Kuberise for Enhanced Kubernetes Support

Description:

As part of our continuous effort to improve Kuberise, we propose integrating K8sGPT to enhance Kubernetes support and troubleshooting capabilities. K8sGPT is an AI-powered tool that helps diagnose and solve Kubernetes-related issues, which will provide significant value to our users by simplifying the management and maintenance of Kubernetes clusters.

Goals:

1. Integrate K8sGPT into the Kuberise platform.
2. Ensure seamless interaction between Kuberise and K8sGPT.
3. Provide documentation and examples for users to leverage K8sGPT within Kuberise.

Tasks:

1. Research and Evaluation

   • Assess the compatibility of K8sGPT with the current Kuberise architecture.
   • Identify potential challenges and solutions for integration.

2. Implementation

   • Develop the integration module to connect K8sGPT with Kuberise.
   • Ensure the module supports key functionalities of K8sGPT, such as diagnosing and suggesting fixes for common Kubernetes issues.
   • Implement authentication and authorization mechanisms to secure the integration.

3. Documentation

   • Create comprehensive documentation detailing the integration process.
   • Provide usage examples and best practices for leveraging K8sGPT within Kuberise.
   • Update the Kuberise user guide and API documentation accordingly.

Benefits:

• Streamlined Kubernetes issue detection and resolution.
• Improved user experience with proactive troubleshooting assistance.
• Enhanced platform stability and reliability.

References:

• k8sgpt.ai
• k8sgpt in github

Internal and external ingress-nginx controller

Title: Integrate Internal and External ingress-nginx for Internal and External Services

Description:

To enhance the flexibility and security of Kuberise, we propose integrating both internal and external ingress-nginx controllers. This will allow us to manage internal services separately from external services, providing better control over traffic routing, security policies, and resource allocation.

Objectives:

1. Deploy two instances of ingress-nginx controllers:
   • Internal ingress-nginx: Handles traffic for services that are only accessible within the cluster.
   • External ingress-nginx: Manages traffic for services that need to be exposed outside the cluster.
2. Ensure that both ingress-nginx controllers can coexist without conflicts.
3. Provide configurations and templates for easy setup and customization.
4. Document the setup and usage guidelines for developers and platform engineers.

Tasks:

1. Setup Helm charts:

   • Modify existing Helm charts or create new ones to support dual ingress-nginx deployment.
   • Include configuration options for internal and external ingress-nginx controllers.

2. Configuration:

   • Define separate namespaces and resource quotas for internal and external ingress-nginx controllers.
   • Set up appropriate RBAC rules to restrict access and control over each ingress controller.

3. Ingress Class Definitions:

   • Create distinct ingress classes for internal and external services.
   • Ensure that internal services are only routed through the internal ingress-nginx and vice versa.

4. Annotations and Labels:

   • Implement necessary annotations and labels for services to specify which ingress controller should handle the traffic.

5. Documentation:

   • Write comprehensive documentation detailing:
     • The purpose and benefits of using dual ingress-nginx controllers.
     • Step-by-step instructions for setting up and configuring both internal and external ingress-nginx.
     • Best practices for maintaining and troubleshooting the ingress controllers.

6. Testing:

   • Perform thorough testing to ensure that both ingress controllers function as expected.
   • Validate that internal services are not accessible from outside the cluster.
   • Confirm that external services are correctly exposed and accessible.

Benefits:

• Improved security by isolating internal traffic from external exposure.
• Enhanced control over resource allocation for ingress traffic.
• Simplified management of services with clear segregation of internal and external endpoints.
• Greater flexibility in applying security policies and traffic routing rules.

How can I make a dev-environment available with a single command?

Hi Mojtaba

Thanks for your work. Kuberise is really a great platform! Keep it up!

However, maybe you can help me with the following. I have a repostory at https://github.com/oidcproxydotnet/OidcProxy.Net.Dev which i want to use to provide a development environment for whoever wants to contribute to the OidcProxy.Net project. But it's a lot of work to explain how to initially start the Kuberise platform. Hence my question: Would it be able to provide a simple, memorable way to Set up kuberise initially?

I notice there's some troubleshooting to do in the following situations:

• What if i don't have minikube or kind? Is it possible to warn the user and tell him/her to go get it?
• Is it possible to automate starting the cluster?
• Is it possible to have an indication that the cluster is running successfully and if not to get the logs in one go?

Looking forward to your response,

Thanks again!

Albert

Tekton Integration

I would like to integrate tekton as an automation tool to the kuberise platform.

KeyCloak not working

Hi Mojtaba,

I just installed my cluster and I'm running into the issue that my KeyCloak instance is not working. It says: 'CrashLoopBackOff'. What's the problem? Where can I find the logs anyways?

This is my config:

applications:

  hello:
    enabled: true
    path: values/local-example/applications/dev/hello

  cnpg-database:
    enabled: false
    path: values/local-example/platform/database/

  raw:
    enabled: false
    path: values/local-example/platform/raw

helmCharts:
  keycloak:
    enabled: true

  keycloak-operator:
    enabled: true

  ingress-nginx:
    enabled: false

  kube-prometheus-stack:
    enabled: false

  loki:
    enabled: false

  promtail:
    enabled: false

  cloudnative-pg:
    enabled: false

  pgadmin:
    enabled: false

  cert-manager:
    enabled: false

  backstage:
    enabled: false

  sealed-secrets:
    enabled: false

  ingresses:
    enabled: false

  # Microservice helm charts for the dev environment

  todolist-frontend-dev:
    enabled: false
    values: defaults/applications/dev/todolist/frontend/values.yaml

  todolist-backend-dev:
    enabled: false
    values: defaults/applications/dev/todolist/backend/values.yaml

  show-env-dev:
    enabled: false
    values: defaults/applications/dev/show-env/values.yaml

# Microservice helm charts for the tst environment

  todolist-frontend-tst:
    enabled: false
    values: defaults/applications/tst/todolist/frontend/values.yaml


# Microservice helm charts for the prd environment

  todolist-frontend-prd:
    enabled: false
    values: defaults/applications/prd/todolist/frontend/values.yaml

Automate DNS Record Update

Automate DNS Record Update for Kuberise Deployment to EKS

Description:

Currently, the process of updating the CNAME DNS record in Cloudflare after deploying Kuberise to EKS is manual. This involves waiting for the deployment to complete, copying the DNS address of the load balancer, and then logging into Cloudflare to update the CNAME record for eks.kuberise.dev. We need to automate this process to streamline our deployment workflow.

Requirements:

1. Set up External DNS for Kubernetes:

   • Install and configure External DNS in a EKS cluster to manage DNS records automatically.
   • Ensure External DNS is configured to use Cloudflare as the DNS provider.

2. Permissions:

   • Ensure the Cloudflare API token has the necessary permissions to edit DNS records for the relevant zone.

3. Service Annotation:

   • Annotate the Kuberise service with the appropriate DNS settings to inform External DNS about the desired hostname (*.eks.kuberise.dev).

Steps:

1. **Add External DNS to the platform tools

   • add a new item in values.yaml and values-eks-example.yaml in app of apps:**
   • add a values.yaml in external-dns folder in values/eks-example folder to add Cloudflare provider settings.

2. Annotate Kuberise Service:

   • Annotate the ingress-nginx loadbalancer service with the hostname *.eks.kuberise.dev.

3. Deploy and Verify:

   • Deploy Kuberise and ensure External DNS updates the Cloudflare DNS records automatically.

4. Monitoring and Testing:

   • Monitor the External DNS logs to verify it is working as expected.
   • Test the deployment to ensure the DNS record *.eks.kuberise.dev is updated correctly in Cloudflare.

Acceptance Criteria:

• External DNS is successfully installed and configured in the EKS cluster.
• Kuberise service is correctly annotated, and the DNS record *.eks.kuberise.dev is automatically updated in Cloudflare after deployment.
• Documentation is updated to reflect the new automated DNS update process.

This automation will significantly reduce the manual overhead involved in the deployment process and ensure that DNS records are always up-to-date, improving our deployment efficiency and reliability.

Keycloak Operator

I would like to add keycloak operator and to create a realm called "platform" for internal applications. Since the official keycloak operator doesn't have helm chart to install operator, I use EDP Keycloak operator. It has a page in operatorhub as well.

Multiple self-signed CA

I would like to create two self signed CA:

• one that is generated externally by the user and added as a secret to the cluster
• and second one that is generated automatically inside the cluster

The install.sh script will check for a ca.crt and ca.key file in .env/[PlatformName] folder in root folder. If it contains already the CA and private key, it will create a secret and deploy the CA to the cert-manager namespace. If not, it will generate a new crt and key and add them to the .env/[PlatformName] folder as well.

Tasks:

• Ignore all files and path including .env in .gitignore
• Generate CA if it doesn't exist in .env/[PlatformName] folder using openssl command
• Mention in the pre-requisite that openssl command is also needed to be available