Skip to content
This repository has been archived by the owner on Sep 14, 2020. It is now read-only.

Use it? Tell us. #100

Open
nolar opened this issue Jun 2, 2019 · 16 comments
Open

Use it? Tell us. #100

nolar opened this issue Jun 2, 2019 · 16 comments
Labels
documentation Documentation improvements

Comments

@nolar
Copy link
Contributor

nolar commented Jun 2, 2019

We are happy to know that you like Kopf, and can apply it in your work.

We will be even more happy if you share with us how you use it: operators created, patterns invented, problems solved, so on. Repos? Posts? Demos? Talks? Presentations? — Everything counts.

In additional to the emotional reward for creating a useful tool, this will help us to decide on the feature roadmap, and to adjust Kopf to the real needs of real users.

For bugs, ideas, feature requests, or just questions, please open a new issue — so that other developers and users can find it later.

@nolar nolar pinned this issue Jun 2, 2019
@nolar nolar changed the title Use it? Tell us! Use it? Tell us. Jun 5, 2019
@mzizzi
Copy link

mzizzi commented Jun 15, 2019

PoC for managing DataDog Monitor resources via kube: https://github.com/mzizzi/datadog_operator

@viruzzo
Copy link

viruzzo commented Aug 27, 2019

Bridge for automatically syncing DNS entries for ingresses and services into MAAS through its API; hacky, but trying to collate a number of different systems together.

@nolar nolar added the documentation Documentation improvements label Oct 22, 2019
@mtparet
Copy link

mtparet commented Nov 24, 2019

I built a first POC in 2 hours to automatically sync secrets from auth0.
Very nice and easy framework/tool!

@janvdvegt
Copy link

We are currently using metacontroller for one of our CRDs but it is deprecated and I did not like some of the choices so for a second CRD I'm trying out kopf. So far I think it looks better. Our system basically wraps code of our users with some of our own code and this code is executed in multiple places in our system. Our first use case will be a wrapper around Jobs that build specific Docker images if not available yet. This way other services can request these asynchronously. The controller will lookup whether these exist already. If not it will create a Job to make and push them, if they exist already it will just put the status to Done. Other services can just interact with these CRD instances then. This also allows us to migrate more easily by creating a bunch of custom resources when we update our own code.

@bukowa
Copy link

bukowa commented Jan 26, 2020

https://github.com/bukwp/kopfmysql some throw away code but works. The only hard thing to figure out was testing. I found https://github.com/vapor-ware/kubetest nice project but needs some love, i was thinking about some wrapper around K8s py API. Later i tried to create generic dataclasses to define multiple and more complicated crds logic around secret that could be later easy imported into kopf. See https://github.com/bukwp/kopfmysql/tree/v1alpha2/kopfmysql/kopfmysql i generally love the abstraction and idea of defining crd as a class, like dataclass which already gives nice Type hints that could be used to generate crds in yaml files with methods on the class to handle create update etc sounds briliant to me. Lookup between other resources automatically (see what i tried in secret.py and later mysqlapi) and fields validation based on Type hint could be achieved. Sorry for formatting and errors

@whereismyjetpack
Copy link

Hi! I am creating an operator that takes a list of keys, generates random passwords, and creates a secret with those generated values. The idea is for containers that read default credentials from a secret, e.g MYSQL_PASSWORD I can have the operator generate them, and then inject the secret into each pod without needing to manually generate and provide them

@dahateb
Copy link

dahateb commented Mar 4, 2020

We built an operator based on kopf to manage the aws eks aws-auth configmap (as decribed here: https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) through custom resources.

https://github.com/TierMobility/aws-auth-operator

@rvlane
Copy link

rvlane commented Mar 11, 2020

I was looking at using kopf for our mariadb operator, however we are using a centos8 distribution deploying python 3.6.8. I assume that since kopf requires python-3.7 that you are using specific feature of that release? We are tied by the centos distribution so it is unfortunate that kopf isn't supported on python 3.6. Just looking for confirmation that kopf would not be compatible with python 3.6. Thanks

@nolar
Copy link
Contributor Author

nolar commented Mar 11, 2020

@rvlane Yes, you are right. Kopf requires Python 3.7+. See #74 — it was already bound to some of the 3.7 core features a year ago when it was starting and had only few features; and now, Kopf is dependant on many more 3.7+ features, which makes 3.6 support impossible (or highly effortful).

Please consider using pyenv for isolated binary Python 3.7 builds from source, maybe some backported pre-built packages or repositories (note sure how this works in CentOS), or docker containers / k8s pods based on Python 3.7.

@nolar
Copy link
Contributor Author

nolar commented Apr 21, 2020

@eshepelyuk Can you please create a separate issue for that?

@eshepelyuk
Copy link

@nolar does kopf have any social communications tools, like gitter, twitter, slack ?

@nolar
Copy link
Contributor Author

nolar commented Apr 23, 2020

@eshepelyuk No (yet). Twitter @nolar is one way to reach me. I am also passively present in https://kubernetes.slack.com/ — there is no special chat room for Kopf, so #kubernetes-operators is a good place to start (maybe) — I have instant notifications when someone mentions me.

For feature requests and questions, it is better to use issues here in GitHub — so that the answers can be seen by others in the future; and maybe as a backlog for follow-up improvements based on the developer's feedback.

@corka149
Copy link

With Kopf we implemented an operator. It helps us to control the number of rising systems. This includes tasks like informing people, keeping things update-to-date, keep the system calm.

I am very excited about the coming daemon-decorator.

@asteven
Copy link

asteven commented May 13, 2020

I'm using kopf to write a dynamic Persistent Volume provisioner for ZFS (zfs-provisioner).

I am basically rewriting my local-zfs-provisioner from golang to python because the upstream go libs have some issues I can not and don't want to deal with.

Thanks to you, I can code in python instead of in golang.
\o/

I don't see myself going back ;-)

@thesolution90
Copy link

I am using kopf for an automated provisioning of secrets and configmaps across namspaces. Therefore I introduced two crds called clusterconfigmap and clustersecret. You can also specify namespace white- or blacklist.
Repo
A lot of other ideas are in the pipeline for development.

@olivier-mauras
Copy link

olivier-mauras commented Sep 14, 2020

We use kopf for a couple of critical controllers.
One is populating - and keeping them as is - namespaces with required configuration like default psp/deployment service accounts, default or custom network policies, etc...
Another one is handling all the resources cleaning - Matching a configuration in a CRD - across our different clusters, from unbounded PV, to review app deployments on dev clusters.
We also have several different other minor ones that are provisioning resources based on different criterias... Most of them are deploy and forget :)

Kopf is de-facto our way to go when we need to implement a custom controller on Kubernetes.

@nolar nolar unpinned this issue Sep 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Documentation improvements
Projects
None yet
Development

No branches or pull requests