Adds the practical elements for lesson 1 of the GitOps tutorial series.

[alexcreasy]

NOTE: This PR is first in a stack of 3 PRs and must be merged before the others:

• Adds the practical elements for lesson 1 of the GitOps tutorial series. #19 [THIS]
• Creates GitOps tutorial Lesson 2: Promoting from Stage to Production #20
• Adds GitOps interactive lesson 3 - rollback a breaking change #21

This adds the first lesson for the GitOps tutorial series.

To run

Checkout the README.md in the lessons/ directory which will point you to instructions to setup the infrastructure and then to the first lesson.

Note: the documentation is to give an idea of how the lesson will go. In a later PR the prose will be re-written to improve the flow, make them more engaging and better elaborate on the lessons as required.

Closes: #8

[tomncooper]

How does the examples/tutorial-poc fit into this? Doesn't the lesson replace the need for that?

[alexcreasy]

@tomncooper ahh yes, my mistake, that should have been removed in my cleanup step!

I've removed it.

[tomncooper]

This is a good first instalment. I ran through lesson 00 and 01. It all works on Kind running in Podman on my Fedora 44 box.

I left some initial comments. You said the prose will be revised so I didn't dive to deep on that.

My only other comment is that it would be good to add a minikube deployment flow into the scripts as the combination of Kind and Minikube probably covers most of the local K8s dev installations.

[tomncooper]

The kafka cluster name and namespace should be parameterised and added to a common script file that all the tutorial scripts source.

[tomncooper]

Should we build the git tea URL once in the common script to save doing it every time?

[tomncooper]

Suggested change

In traditional operations you make changes to a running system by running commands directly against it — `kubectl apply`, a config panel, an API call. GitOps flips this around: a Git repository is the single source of truth for what the system should look like. A tool (in this case ArgoCD) watches the repository and continuously reconciles the live system to match. If Git says a topic should exist, the topic exists. If you remove it from Git, it disappears from the cluster. You never touch the system directly; you only change Git.

In traditional operations you make changes to a running system by running commands directly against it — `kubectl apply`, a config panel, an API call. GitOps flips this around: a Git repository is the single source of truth for what the system should look like. A tool (in this case ArgoCD) watches the repository and continuously reconciles the live system to match. If the config in the git repository says a topic should exist, then the topic will be created. If you remove it from the config repository, it disappears from the cluster. You never touch the system directly; you only change the configuration in the repo. You now have, thanks to git, a record of all the changes made, when they were made and by who. You can also setup all kinds of sanity and safety checks to run against those changes before they are applied.

[tomncooper]

Suggested change

	That YAML file, committed to the Git repository, is the complete description of this Kafka cluster. ArgoCD read it from Git and the Strimzi operator created the cluster from it. You didn't run any `kubectl apply` commands — the setup script pushed the file to Git and ArgoCD took it from there.
	That YAML file, committed to the Git repository, is the complete description of this Kafka cluster. ArgoCD read it from the repo, applied to the kubernetes cluster and the Strimzi operator created the Kafka cluster from it. You didn't run any `kubectl apply` commands — the setup script pushed the file to the Git repo and ArgoCD took it from there.

[tomncooper]

I wouldn't expect any housekeeping topics there? The TopicOperator only does one-way sync from k8s > Kafka, it won't create KafkaTopic CRs for topics in kafka which aren't in k8s.

I wonder if we should use the actual kafka topic commands here to interrogate the kafka cluster directly and show there are currently no topics?

Something like:

kubectl -n kafka-tutorial exec -it my-cluster-combined-0 -- bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --list