Syched from supertubes rebranding 20230417 (#105)

* Typo corrections

# Conflicts:
#	docs/ssl.md

* Fix writing convention of ZooKeeper, and add some Apache references

# Conflicts:
#	docs/install-kafka-operator.md
#	docs/troubleshooting/_index.md

* Added the features of Koperator to the main page (#101)

* Added the features of Koperator to the main page

* Incorporated review comments

---------

Co-authored-by: Arati Chilad <[email protected]>
# Conflicts:
#	docs/_index.md
#	docs/features.md

* Update commands and wordings (#104)


# Conflicts:
#	docs/install-kafka-operator.md

docs/_index.md

@@ -2,6 +2,8 @@
 title: Koperator
 img: /docs/supertubes/kafka-operator/img/kafka-operator-arch.png
 weight: 700
+aliases:
+  - /docs/supertubes/kafka-operator/features/
 cascade:
   module: kafka-operator
   githubEditUrl: "https://github.com/banzaicloud/koperator-docs/edit/master/docs/"
@@ -27,20 +29,113 @@ The {{< kafka-operator >}} (formerly called Banzai Cloud Kafka Operator) is a Ku
 
 ![{{< kafka-operator >}} architecture](./img/kafka-operator-arch.png)
 
-
->We took a different approach to what's out there - we believe for a good reason - please read on to understand more about our [design motivations](features/) and some of the [scenarios](scenarios/) which drove us to create the {{< kafka-operator >}}.
-
 {{% include-headless "doc/kafka-operator-supertubes-intro.md" %}}
 
 ## Motivation
 
 Apache Kafka predates Kubernetes and was designed mostly for `static` on-premise environments. State management, node identity, failover, etc all come part and parcel with Kafka, so making it work properly on Kubernetes and on an underlying dynamic environment can be a challenge.
 
 There are already several approaches to operating Apache Kafka on Kubernetes, however, we did not find them appropriate for use in a highly dynamic environment, nor capable of meeting our customers' needs. At the same time, there is substantial interest within the Kafka community for a solution which enables Kafka on Kubernetes, both in the open source and closed source space.
->We took a different approach to what's out there - we believe for a good reason - please read on to understand more about our [design motivations](features/) and some of the [scenarios](scenarios/) which were driving us to create the {{< kafka-operator >}}.
 
->We took a different approach to what's out there - we believe for a good reason - read on to understand more about our [design motivations](features/) and some of the [scenarios](scenarios/) which were driving us to create the Banzai Cloud Kafka operator.
+> We took a different approach to what's out there - we believe for a good reason - please read on to understand more about our [design motivations](#features) and some of the [scenarios](scenarios/) which were driving us to create the {{< kafka-operator >}}.
 
 Finally, our motivation is to build an open source solution and a community which drives the innovation and features of this operator. We are long term contributors and active community members of both Apache Kafka and Kubernetes, and we hope to recreate a similar community around this operator.
 
+## Koperator features {#features}
+
+### Design motivations
+
+Kafka is a stateful application. The first piece of the puzzle is the Broker, which is a simple server capable of creating/forming a cluster with other Brokers. Every Broker has his own **unique** configuration which differs slightly from all others - the most relevant of which is the ***unique broker ID***.
+
+All Kafka on Kubernetes operators use [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) to create a Kafka Cluster. Just to quickly recap from the K8s docs:
+
+>StatefulSet manages the deployment and scaling of a set of Pods, and provide guarantees about their ordering and uniqueness. Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains sticky identities for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that is maintained across any rescheduling.
+
+How does this look from the perspective of Apache Kafka?
+
+With StatefulSet we get:
+
+- unique Broker IDs generated during Pod startup
+- networking between brokers with headless services
+- unique Persistent Volumes for Brokers
+
+Using StatefulSet we **lose:**
+
+- the ability to modify the configuration of unique Brokers
+- to remove a specific Broker from a cluster (StatefulSet always removes the most recently created Broker)
+- to use multiple, different Persistent Volumes for each Broker
+
+{{< kafka-operator >}} uses `simple` Pods, ConfigMaps, and PersistentVolumeClaims, instead of StatefulSet. Using these resources allows us to build an Operator which is better suited to manage Apache Kafka.
+
+With the {{< kafka-operator >}} you can:
+
+- modify the configuration of unique Brokers
+- remove specific Brokers from clusters
+- use multiple Persistent Volumes for each Broker
+
+## Features
+
+### Fine Grained Broker Configuration Support
+
+We needed to be able to react to events in a fine-grained way for each Broker - and not in the limited way StatefulSet does (which, for example, removes the most recently created Brokers). Some of the available solutions try to overcome these deficits by placing scripts inside the container to generate configurations at runtime, whereas the {{< kafka-operator >}}'s configurations are deterministically placed in specific Configmaps.
+
+### Graceful Kafka Cluster Scaling with the help of our CruiseControlOperation custom resource
+
+We know how to operate Apache Kafka at scale (we are contributors and have been operating Kafka on Kubernetes for years now). We believe, however, that LinkedIn has even more experience than we do. To scale Kafka clusters both up and down gracefully, we integrated LinkedIn's [Cruise-Control](https://github.com/linkedin/cruise-control) to do the hard work for us. We already have good defaults (i.e. plugins) that react to events, but we also allow our users to write their own.
+
+### External Access via LoadBalancer
+
+The {{< kafka-operator >}} externalizes access to Apache Kafka using a dynamically (re)configured Envoy proxy. Using Envoy allows us to use **a single** LoadBalancer, so there's no need for a LoadBalancer for each Broker.
+
+![Kafka External Access](../img/kafka-external.png)
+
+### Communication via SSL
+
+The operator fully automates Kafka's SSL support.
+The operator can provision the required secrets and certificates for you, or you can provide your own.
+
+![SSL support for Kafka](../img/kafka-ssl.png)
+
+### Monitoring via Prometheus
+
+The {{< kafka-operator >}} exposes Cruise-Control and Kafka JMX metrics to Prometheus.
+
+### Reacting on Alerts
+
+{{< kafka-operator >}} acts as a **Prometheus Alert Manager**. It receives alerts defined in Prometheus, and creates actions based on Prometheus alert annotations.
+
+Currently, there are three default actions (which can be extended):
+
+- upscale cluster (add a new Broker)
+- downscale cluster (remove a Broker)
+- add additional disk to a Broker
+
+### Graceful Rolling Upgrade
+
+Operator supports graceful rolling upgrade, It means the operator will check if the cluster is healthy.
+It basically checks if the cluster has offline partitions, and all the replicas are in sync.
+It proceeds only when the failure threshold is smaller than the configured one.
+
+The operator also allows to create special alerts on Prometheus, which affects the rolling upgrade state, by
+increasing the error rate.
+
+### Dynamic Configuration Support
+
+Kafka operates with three type of configurations:
+
+- Read-only
+- ClusterWide
+- PerBroker
+
+Read-only config requires broker restart to update all the others may be updated dynamically.
+Operator CRD distinguishes these fields, and proceed with the right action. It can be a rolling upgrade, or
+a dynamic reconfiguration.
+
+### Seamless Istio mesh support
+
+- Operator allows to use ClusterIP services instead of Headless, which still works better in case of Service meshes.
+- To avoid too early Kafka initialization, which might lead to unready sidecar container. The operator uses a small script to mitigate this behavior. Any Kafka image can be used with the only requirement of an available **curl** command.
+- To access a Kafka cluster which runs inside the mesh. Operator supports creating Istio ingress gateways.
+
+---
 Apache Kafka, Kafka, and the Kafka logo are either registered trademarks or trademarks of The Apache Software Foundation in the United States and other countries.

docs/benchmarks/_index.md

@@ -7,7 +7,7 @@ How to setup the environment for the Kafka Performance Test.
 
 ## GKE
 
-1. Create a test cluster with 3 nodes for Zookeeper, 3 for Kafka, 1 Master node and 2 node for clients.
+1. Create a test cluster with 3 nodes for ZooKeeper, 3 for Kafka, 1 Master node and 2 node for clients.
 
     Once your cluster is up and running you can set up the Kubernetes infrastructure.
 
@@ -28,7 +28,7 @@ How to setup the environment for the Kafka Performance Test.
 
 ## EKS
 
-1. Create a test cluster with 3 nodes for Zookeeper, 3 for Kafka, 1 Master node and 2 node for clients.
+1. Create a test cluster with 3 nodes for ZooKeeper, 3 for Kafka, 1 Master node and 2 node for clients.
 
     {{< include-headless "warning-ebs-csi-driver.md" "supertubes/kafka-operator" >}}
 
@@ -53,7 +53,7 @@ How to setup the environment for the Kafka Performance Test.
 
 ## Install other required components
 
-1. Create a Zookeeper cluster with 3 replicas using Pravega's Zookeeper Operator.
+1. Create a ZooKeeper cluster with 3 replicas using Pravega's Zookeeper Operator.
 
     ```bash
     helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com/

docs/create-zookeeper.sample

@@ -1,4 +1,4 @@
-kubectl create --namespace zookeeper -f - <<EOF
+kubectl create -f - <<EOF
 apiVersion: zookeeper.pravega.io/v1beta1
 kind: ZookeeperCluster
 metadata:

docs/developer.md

@@ -41,7 +41,7 @@ Alternatively, run the operator on your machine:
 
 Create CR and let the operator set up Kafka in your cluster (you can change the `spec` of `Kafka` for your needs in the yaml file):
 
-> Remember you need Zookeeper server to run Kafka
+> Remember you need an Apache ZooKeeper server to run Kafka
 
 `kubectl create -n kafka -f config/samples/simplekafkacluster.yaml`
 

docs/install-kafka-operator.md

@@ -18,7 +18,7 @@ The operator installs version 3.1.0 of Apache Kafka, and can run on:
 
 - A Kubernetes cluster (minimum 6 vCPU and 10 GB RAM). Red Hat OpenShift is also supported in {{< kafka-operator >}} version 0.24 and newer, but note that it needs some permissions for certain components to function.
 
-> We believe in the `separation of concerns` principle, thus the {{< kafka-operator >}} does not install nor manage Zookeeper or cert-manager. If you would like to have a fully automated and managed experience of Apache Kafka on Kubernetes, try [Banzai Cloud Supertubes](/products/supertubes/).
+> We believe in the `separation of concerns` principle, thus the {{< kafka-operator >}} does not install nor manage Apache ZooKeeper or cert-manager. If you would like to have a fully automated and managed experience of Apache Kafka on Kubernetes, try [Cisco Streaming Data Manager](https://calisti.app).
 
 ## Install {{< kafka-operator >}} and all requirements using Supertubes
 
@@ -213,12 +213,12 @@ This method uses a command-line tool of the commercial [Banzai Cloud Supertubes]
 
 ### Install zookeeper-operator with Helm {#install-zookeeper-operator-with-helm}
 
-{{< kafka-operator >}} requires [Zookeeper](https://zookeeper.apache.org) for Kafka operations. You must:
+{{< kafka-operator >}} requires [Apache Zookeeper](https://zookeeper.apache.org) for Kafka operations. You must:
 
 - Deploy zookeeper-operator if your environment doesn't have an instance of it yet.
 - Create a Zookeeper cluster if there is none in your environment yet for your Kafka cluster.
 
-> Note: It is recommended to create a separate Zookeeper deployment for each Kafka cluster. To share the same Zookeeper cluster across multiple Kafka cluster instances, use a unique zk path in the KafkaCluster CR to avoid conflicts (even with previous defunct KafkaCluster instances).
+> Note: You are recommended to create a separate ZooKeeper deployment for each Kafka cluster. If you want to share the same ZooKeeper cluster across multiple Kafka cluster instances, use a unique zk path in the KafkaCluster CR to avoid conflicts (even with previous defunct KafkaCluster instances).
 
 1. If you are installing zookeeper-operator on a Red Hat OpenShift cluster, elevate the permissions of the namespace containing the Zookeeper service account.
 
@@ -240,7 +240,7 @@ This method uses a command-line tool of the commercial [Banzai Cloud Supertubes]
     clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "system:serviceaccounts:{NAMESPACE_FOR_ZOOKEEPER_SERVICE_ACCOUNT}"
     ```
 
-1. Install Zookeeper using the [Pravega's Zookeeper Operator](https://github.com/pravega/zookeeper-operator).
+1. Install ZooKeeper using the [Pravega's Zookeeper Operator](https://github.com/pravega/zookeeper-operator).
 
     ```bash
     helm install \

docs/scenarios.md

@@ -5,7 +5,7 @@ weight: 400
 
 
 
-As highlighted in the [features section](../features/), we removed the reliance on StatefulSet, we support several different scenarios.
+As highlighted in the [features section]({{< relref "../_index.md#features" >}}), we removed the reliance on StatefulSet, we support several different scenarios.
 
 > Note: this is not a complete list, if you have a specific requirement or question, [contact us](/contact/).