Pulsar Operator On Kubernetes

[sky-big]

Add pulsar operator for kubernetes(https://github.com/sky-big/pulsar-operator) based on deployment/kubernetes/*.yaml

[sky-big]

Welcome everyone to contribute

[sky-big]

Basically realized the function of pulsar operator，include pulsar dashboard, grafana, prometheus and so on Pulsar Operator，weclome to use and contribute.

[sky-big]

Next step concern pulsar stateful component(include Bookeeper and Zookeeper), use operator control complex stateful component.

[chrsoo]

Great initiative! I know you have to start somewhere and cannot do everything at once but have you thought about CRD's for Sources and Sinks? What about configuration like Channels, Tenants and Namespaces?

I would really like to get out of an imperative approach based on pulsar-admin for managing the cluster. Still trying to figure out how to get the whole configuration for a geo-replicated cluster in Git...

[wolfstudy]

I would really like to get out of an imperative approach based on pulsar-admin for managing the cluster.

@chrsoo Maybe the pulsar-manager is a good idea for you.

[chrsoo]

@wolfstudy thanks for the tip (I am aware) but how is pulsar-manager not imperative?

A web UI where you do point-and-click is virtually the same thing as issuing commands on the command line. At each instance in time you tell the system what to do instead of telling it the desired target state and have it figure out the changes by itself.

In the end I would like to declare the state of my cluster in an external git repository and then have a CI/CD pipeline provision it for me (gitops).

The CRD proposed by @sky-big is a really good start and I could work with this towards my end goal, but I need to declare other parts of the configuration as well. Point-and-click will not do the job :-)

[sky-big]

@chrsoo Cloud you please give a sepcific example based on your sence? then we can add this function in the pulsar operator.

[chrsoo]

The difficulty here is where to draw the line between more or less static configuration and what should remain dynamically defined at runtime by the clients/users of the system. This might vary in different contexts.

I think it could be useful to define CRDs for the following Pulsar configuration items:

1. Tenants with namespaces and their relation to Clusters
2. Persistent Topics and their relation to tenants/namespaces
3. Sources and Sinks and their relation to clusters/topics

Starting with Tenants the following CRDs might be useful

• PulsarTenant - defines a Pulsar Tenant
• PulsarNamespace - defines a Pulsar Namespace for a Tenant
• PulsarNamespaceBinding - binds a Pulsar Namespace to a PulsarCluster

It would be good if Tenants and Namespaces are defined at the K8s cluster level as a Tenants and Namespaces then could be reused across multiple PulsarClusters defined in the different K8s namespaces. The PulsarNamespaceBinding should be defined at the namespace level and in the same namespace as the PulsarCluster to which it is bound.

@sky-big - does all this make sense to you?

[sky-big]

@wolfstudy @sijie @jiazhai Can you disscuss it together?

[sky-big]

@chrsoo I generally understand what you mean, Starting with Tenants CRDs, Can you make a specific design and let everyone discuss？

[sijie]

@chrsoo @sky-big @wolfstudy I think what @chrsoo request is an operator for the full lifecycle management for all the resources within a Pulsar instance. This includes both ClusterOperator and ResourceOperator.

A ClusterOperator is what @sky-big is doing and most of the operators are doing. It is used for setting up a cluster and managing the upgrade, downgrade and scaling up-and-down a cluster.

A ResourceOperator is more about using CRD for provisioning resources within a Pulsar cluster. A resource such as a role (key and tokens), a tenant, a namespace, a topic, a function and etc.

Once everything is modeled as CRD, you can use kubernetes to provision both cluster and resources. Thus you can apply a GitOps patten in a CI/CD pipeline to manage everything.

@chrsoo : this is kind of aligned with what we (StreamNative) are working on. We shall be able to share what we have done soon.

[chrsoo]

@sijie yes, exactly. Should we take your comment regarding StreamNative to mean that you are planning to open source an Operator for Pulsar on Kubernetes that deals with the full scope of CRD's for Pulsar management? How soon is "soon"?

@sky-big regarding a specific design I would design it as explained above but I will see if I can produce a more detailed design specification as a PR.