Use it? Tell us. about kopf HOT 16 OPEN

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

from kopf.

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

from kopf.

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.

from kopf.

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

from kopf.

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.

from kopf.

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

from kopf.

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

from kopf.

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

from kopf.

@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.

from kopf.

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

from kopf.

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

from kopf.

@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.

from kopf.

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.

from kopf.

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 ;-)

from kopf.

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.

from kopf.

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.

from kopf.