asdf2014 commented on code in PR #16045:
URL: https://github.com/apache/druid/pull/16045#discussion_r1557100195


##########
docs/operations/kubernetes.md:
##########
@@ -25,10 +25,20 @@ title: "kubernetes"
 
 Apache Druid distribution is also available as 
[Docker](https://www.docker.com/) image from [Docker 
Hub](https://hub.docker.com/r/apache/druid) . For example, you can obtain 
latest release using the command below.
 
-```
+```bash
 $ docker pull apache/druid
 ```
 
-[druid-operator](https://github.com/datainfrahq/druid-operator) can be used to 
manage a Druid cluster on [Kubernetes](https://kubernetes.io/) .
+[Apache Druid Helm Chart](https://github.com/asdf2014/druid-helm) can be used 
to deploy a Druid cluster on Kubernetes with following commands:

Review Comment:
   @gianm When deciding between Helm Charts and Operators, the choice depends 
on the complexity of the application and the desired level of operational 
logic. 
   
   Someone might want to use an Operator when they have a stateful application 
that requires advanced lifecycle management, automation of complex tasks like 
failover and scaling, and application-specific operational logic. Operators are 
suitable for managing complex stateful applications.
   
   On the other hand, someone might choose to use a Helm Chart for stateless 
applications or straightforward management tasks where customization options 
through variables are sufficient. Helm Charts are ideal for automating 
deployment and updates but may require manual intervention for operational 
tasks.
   
   For someone familiar with Kubernetes, the choice between Helm Charts and 
Operators may be clearer based on their understanding of the application's 
requirements and the available options. Here is a table, FYI :smile:
   
   |                          |                          Helm Chart             
             |                           Operator                           |
   | :----------------------: | 
:----------------------------------------------------------: | 
:----------------------------------------------------------: |
   |      **Definition**      | A package manager for Kubernetes that uses 
charts to define, install, and upgrade applications. | Extensions of Kubernetes 
API that manage applications and encapsulate operational knowledge in software. 
|
   |      **Complexity**      |             Relatively simple to create and 
use.             | More complex to create; requires knowledge of Kubernetes 
internals and possibly Go programming. |
   |   **State Management**   | Does not manage the state of an application 
post-deployment. | Designed to manage complex stateful applications with 
operational logic. |
   |    **Customization**     | Supports variables for customization but not 
application-specific operational logic. | Highly customizable with 
application-specific operational logic. |
   |      **Automation**      | Limited to deployment and updates, manual 
intervention required for operational tasks. | Can automate complex tasks such 
as failover, backup, scaling, and self-healing. |
   |       **Use Case**       | Best for stateless applications or when 
management logic is straightforward. | Best for stateful applications requiring 
complex operations and lifecycle management. |
   | **Community & Support**  |  Large community with a vast repository of 
pre-made charts.  | Growing community, especially around popular applications 
that benefit from custom operational logic. |
   |    **Learning Curve**    |            Easier to learn and get started 
with.             | Steeper learning curve due to the need to understand both 
Kubernetes and the specific application deeply. |
   |     **Reusability**      | Charts are reusable across different 
environments with variable substitution. | Operators are generally 
application-specific and not as easily reusable for different applications. |
   | **Lifecycle Operations** |      Basic install, upgrade, and rollback 
capabilities.      | Advanced lifecycle management, including 
application-specific operations like data rebalancing, configuration changes, 
and upgrades. |
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to