cloudogu / k8s-component-operator

k8s-component-operator

Cloudogu EcoSystem component operator for Kubernetes

---

What is the Cloudogu EcoSystem?

The Cloudogu EcoSystem is an open platform, which lets you choose how and where your team creates great software. Each service or tool is delivered as a Dogu, a Docker container. Each Dogu can easily be integrated in your environment just by pulling it from our registry. We have a growing number of ready-to-use Dogus, e.g. SCM-Manager, Jenkins, Nexus, SonarQube, Redmine and many more. Every Dogu can be tailored to your specific needs. Take advantage of a central authentication service, a dynamic navigation, that lets you easily switch between the web UIs and a smart configuration magic, which automatically detects and responds to dependencies between Dogus. The Cloudogu EcoSystem is open source and it runs either on-premises or in the cloud. The Cloudogu EcoSystem is developed by Cloudogu GmbH under MIT License.

How to get in touch?

Want to talk to the Cloudogu team? Need help or support? There are several ways to get in touch with us:

• Website
• myCloudogu-Forum
• Email [email protected]

---

© 2023 Cloudogu GmbH - MADE WITH ❤️ FOR DEV ADDICTS. Legal notice / Impressum

k8s-component-operator's Issues

Allow insecure TLS communication with helm registry

Read metadata for helm values

Update kube-rbac-proxy

Add helm chart to release process

Track health on component CR

Reset component status in error case

If a component fails to update it remains in the upgrading status and changes to the spec won't be reconciled.
Furthermore the helm rollback is buggy.

PoC: multiple ces in one cluster

Make Helm-Client more generic

The helm-client of the component-operator should be more generic to be usable by other components (e.g. "k8s-ces-setup")

Finalize installation process

Determine latest version of a component

When a component has no version the component-operator should determine the latest version of the component from the configure helm-repository

Add component-patch-template

Extend rbac configuration for longhorn

remove YAML tapestry in favour of helm templates

create component diff

Before any component actions can be derived, the actual differences must be refined.

Handle first-level dependencies between k8s components

like:

A -> B

but not recursively like:

A -> B -> C

Add documentation for creating k8s-ces-components

Add documentation for creating k8s-ces-components

fix missing component upgrade when component has a set deployNamespace

Please fix a missing component upgrade when the component has a set deployNamespace in its CR. Currently there is just one component that is affected by this (which also is only installed and barely upgraded):

github.com/cloudogu/k8s-longhorn

Reimplement go-helm-client ourselves

Add documentation for upgrading components

Initial

Support every special character as password

Improve code-documentation

Add missing godocs

Fix config map that contains concatenated schema and endpoint

This breaks the runtime of cloudogu/k8s-ces-setup because the information is used in separate places in different formats

Separate component-dependencies from helm-dependencies

Separate component-dependencies from helm-dependencies

package and release crds in a separate helm chart

package and release crds in a separate helm chart

Remove k8s components

The k8s-component-operator should be able to remove k8s components from the cluster.

Validate Spec.Name to match ObjectMeta.Name

Upgrade k8s-components

The k8s-component-operator should be able to upgrade k8s components from the cluster.

Configure Helm values.yaml-values in component-CR

Enhance code quality

add installed version to status

Set health status on startup and shutdown

If a shutdown is detected, the health status of the component-operator component should be set to unavailable and the health of all other components to unknown.
On startup, the health of all components should be detected and set.