The previous lesson ended with a RutaProgramada CRD that was perfectly defined, validated and queryable, and on which absolutely nothing happened. And in lesson 06-01 we left another debt: bookings-postgres is a StatefulSet that gives its replicas an identity and a disk, but that cannot choose a primary, replicate data or fail over when that primary dies.

Both gaps have the same solution, and it comes down to one sentence worth memorising:

Operator = custom resource + controller that reconciles it.

An operator is an expert's operational knowledge — how a PostgreSQL replica is promoted, how a consistent backup is taken, how a major version is upgraded without losing data — encoded in software that runs inside the cluster and never sleeps.

This is the last lesson of the module. We will settle the two outstanding debts, look inside the reconciliation loop, replace our hand-rolled StatefulSet with a real PostgreSQL operator, sketch out the RutaProgramada controller, and finish by explaining why most teams should not write operators.

1. What an operator is, precisely
2. The real anatomy of the reconciliation loop
3. Idempotency and no state in memory
4. The five-level capability model
5. Operators you have already used in this course
6. A practical case: a PostgreSQL operator for bookings-postgres
7. Where to find operators and what to check before adopting one
8. How one is written: Kubebuilder and controller-runtime
9. ownerReferences and cascading deletion
10. When NOT to write an operator

An operator has exactly two pieces:

1. One or more CRDs that define the vocabulary: Cluster, Certificate, RutaProgramada. It is the declarative interface with which the user expresses what they want.
2. A controller — normally a Deployment running in the cluster itself — that watches those objects and does the work.

The term was coined by CoreOS in 2016 with this idea: when an operations team has been administering PostgreSQL for years, it has accumulated a set of procedures — what to do if the primary stops answering, how to add a read replica, in what order to upgrade — that live in runbooks, in scattered scripts and in two people's heads. An operator turns all of that into a program that runs continuously.

The difference from the tools you already know:

An operator does not install: it maintains. If somebody deletes a pod, it recreates it. If the primary goes down at three in the morning, it promotes a replica without waking anybody. If the disk fills up, it expands it. That permanent vigilance is its value.

In lesson 01-02 we described the reconciliation loop as the central idea of Kubernetes: observe the desired state, observe the real one, act to bring them together. Now we look inside it, as any serious controller implements it.

The controller does not poll the API in a loop: it opens a watch connection and receives a notification of every change. The standard library (client-go) wraps that in an informer, which also maintains a local cache of every object watched.

The cache matters for two reasons:

• The controller's reads do not hit the apiserver: on a cluster with hundreds of objects, the difference is substantial.
• The cache may be slightly out of date. A controller has to tolerate reading an object a couple of seconds behind, which reinforces the need for idempotency.

Events are not processed directly: each is translated into a key (namespace/name) and put into a queue with three properties:

• Deduplication: if an object changes five times while it is being processed, the key appears only once. It will be reconciled once with the final state, not five times with intermediate ones.
• Delay: you can ask for "look at this again in 30 seconds", useful for waiting until something external makes progress.
• Rate limiting with exponential backoff: a failing object is retried after 5 ms, 10 ms, 20 ms… up to a maximum. A permanently broken object does not consume the whole controller.

It is the heart of it, and its signature says a lot:

It receives only a key, not the object and not the event. That design decision is deliberate: Reconcile does not know what changed or why it was called. Its contract is always the same: given this name, read the desired state, look at the real one, and make them match.

It returns two things:

The last step of every reconciliation is writing what was observed into .status, through the subresource we studied in 06-06. Here a conventional field appears that deserves an explanation:

metadata.generation is incremented by the apiserver every time the spec changes (not when labels or annotations change). The controller stores in status.observedGeneration the generation it has already processed. By comparing the two, anybody can tell whether the controller is up to date:

If they differ, there is a spec change the controller has not attended to yet.

Two non-negotiable properties of any Reconcile.

Reconcile can run many more times than you expect: because of a real change, because of a retry after an error, because of a periodic resync of the informer (every 10 hours by default), or simply because the controller restarted and is reconciling everything that exists.

That is why Reconcile must never think in terms of "create" but of "make sure it exists":

A practical corollary: a reconciliation that changes nothing is the normal case and must be cheap. If your Reconcile writes to the API on every pass even when nothing has changed, you will cause an infinite loop: the write generates an event, the event triggers another reconciliation, and so on indefinitely. It is the classic mistake in everybody's first operator, and it is spotted because the apiserver records thousands of updates per minute on the same object.

The controller cannot remember anything between reconciliations. Not in global variables, not in maps, not in local files.

The reasons:

• It can restart at any moment (an update, an eviction, a node failure) and would lose everything.
• There may be several replicas for high availability; only one is active thanks to leader election, but the handover can happen at any time.
• In-memory state drifts out of sync with the real world without anybody noticing.

All the state the controller needs to remember must live in the Kubernetes API: in .status, in annotations, in labels or in the objects it manages. If your operator needs to know "I already ran today's backup", that goes in status.lastBackup, not in a variable.

The positive consequence is that a well-written operator can be killed and started at any moment with no side effects. It is a property worth testing deliberately: delete the controller's pod halfway through an operation and check that it picks up correctly.

The Operator Framework project defined a scale for measuring how much an operator knows how to do. It is the best tool for evaluating one before adopting it. Applied to a database like bookings-postgres:

What each jump adds, in detail:

Level 1 → 2: upgrading stops being a manual procedure. The operator knows the replicas have to be updated first and the promotion done afterwards, and that each one has to be waited for while it syncs.

Level 2 → 3: here is the bulk of the value. Scheduled backups with verification, point-in-time restore, adding a read replica with a single change in the spec, changing shared_buffers without dropping connections.

Level 3 → 4: the operator stops being a black box. It publishes metrics for replication lag, database size and backup state, and its status tells the truth about what is going on.

Level 4 → 5: automatic failover. It is the level that separates "it saves me work" from "I can sleep at night". It is also the hardest and the one requiring the most care: an operator that fails over badly can cause a split brain with two primaries accepting writes.

When evaluating an operator, ask about the level. Many flashy projects stop at 2, and for level 2 the added complexity is not worth it: a Helm chart already does that.

Without calling them that, we have been using operators for several modules.

When we applied a Certificate for www.rutasnorte.example, the following happened without us doing anything else:

1. The cert-manager controller observed the new Certificate object.
2. It created a CertificateRequest, generated a private key and stored it in a Secret.
3. It created an Order and a Challenge for the ACME protocol.
4. It published a temporary Ingress with the HTTP-01 challenge token.
5. It waited for Let's Encrypt to validate, obtained the certificate and wrote it into the Secret.
6. And ever since it has been watching the expiry date and repeats the process 30 days before it expires.

Step 6 is the definition of an operator. A script would have done steps 1 to 5; only a controller that runs forever does step 6. In capability terms, cert-manager is at level 5 for its domain: it renews with no human intervention.

Three Deployments: the controller, a CA certificate injector and the validating webhook for its CRDs. It is the typical anatomy of a mature operator.

When we created a VolumeSnapshot of the bookings data, a controller observed it, talked to the CSI driver, created the corresponding VolumeSnapshotContent and updated status.readyToUse. Same pattern: a CRD plus a controller.

Its Backup, Restore and Schedule are CRDs, and its controller is what runs the backups, applies the hooks before and after, and honours the retention. A Velero Schedule is an operator creating Jobs, conceptually the same as what the CronJob controller does with our occupancy-reports.

Coming up. Its Prometheus, ServiceMonitor, PodMonitor and PrometheusRule CRDs let you declare "collect metrics from every Service with this label" and the operator generates and reloads the Prometheus configuration. Without it, adding a new target means hand-editing a configuration file hundreds of lines long.

It is worth closing the circle: the Deployment controller, the ReplicaSet one and the Job one work in exactly the same way. They watch objects, compare desired with observed and act. The only difference is that their types come built in and their code lives inside the kube-controller-manager rather than in a separate Deployment. The pattern is identical; operators simply extend it to domains Kubernetes does not know about.

We come to the debt from 06-01. Our hand-rolled StatefulSet has one replica and cannot do anything else. We are going to replace it with CloudNativePG, a mature open-source PostgreSQL operator.

One Deployment (the controller) and four CRDs (the vocabulary). Exactly the two pieces of the definition.

bookings-postgres is now described like this:

The three Services are the piece a StatefulSet cannot provide:

And the essential part: when the primary changes, the operator rewrites the -rw Service so that it points to the new one. The application never notices. That is exactly what a StatefulSet cannot do, because its headless Service gives stable names but does not know which of those names is the primary.

Within seconds: the outage is detected, bookings-postgres-2 is promoted, the -rw Service is rewritten, and the downed instance comes back as a replica. No human intervention, no runbook, no phone call at three in the morning.

That is the whole argument in favour of operators for stateful software: the left-hand column is weeks of work, fragile procedures and night shifts; the right-hand one is fields in a YAML.

With what we learned in 05-06 and 06-01, the migration from our StatefulSet is done by logical restore, not by moving volumes:

The operator starts up, connects to the old StatefulSet, imports the database and builds the new cluster. Afterwards you verify the number of bookings, point bookings-api at the -rw Service and retire the StatefulSet.

Adopting an operator means adopting a dependency that will have broad permissions over your cluster and that your data will depend on. Before installing it:

1. Maintenance. When was the last commit? How many people contribute? Are there regular releases? How many open issues with no response? An abandoned operator managing your database is a serious problem, because uninstalling it without losing data is rarely trivial.

2. The RBAC permissions it asks for. This is the point most often overlooked. Look at it before applying the manifest:

The questions: does it ask for cluster-admin? (an immediate red flag) Does it ask for access to all the cluster's Secrets? Can it create ClusterRoleBindings, that is, widen its own permissions? A compromised operator with broad permissions amounts to a compromised cluster. We will come back to this in 08-01.

3. Maturity. What capability level does it declare and which one does it really meet? Are there documented production use cases? Is there an upgrade guide between versions of the operator itself?

4. What happens if you uninstall it. The decisive question:

• Do the objects it managed keep working, or do they stop?
• Do its CRDs have finalizers that would leave objects hanging in Terminating?
• Can you export the data to a standard format?
• Is there a documented exit procedure?

An operator you cannot get out of is a technological hostage situation. With CloudNativePG, for example, the backups in Barman format are restorable with standard PostgreSQL tools: there is a way out.

5. Resources and scope. How much CPU and memory does the controller use? Does it watch the whole cluster or can it be limited to particular namespaces? An operator watching every object in a large cluster can use a fair amount of memory.

6. Upgrade model. How is the operator upgraded without affecting what it manages? Is it backwards compatible with the CRDs already deployed?

Nobody writes an operator from scratch. The standard tools:

With Operator SDK you can build an operator without writing Go, using a Helm chart or an Ansible playbook as the reconciliation logic. It is a reasonable route for simple operators, though it limits the capabilities to levels 1 and 2.

The generated structure:

The CRD from lesson 06-06 is not written by hand in a real project: it is generated from annotated Go structs.

The // +kubebuilder:... comments are markers the generator translates into the CRD's OpenAPI schema. make manifests produces exactly the YAML we wrote by hand in 06-06, and the ordinary comments become the descriptions that feed kubectl explain.

This is the heart of the RutaProgramada operator: every active route must have its own CronJob generating the occupancy report for that route.

The seven steps are the skeleton of any operator, whether for bus routes or for PostgreSQL: read the desired state, handle the deletion case, build what ought to exist, mark the ownership, create or update only if needed, observe reality and write the status, and decide when to look again.

The Owns(&batchv1.CronJob{}) in SetupWithManager deserves a comment: it makes the controller receive events for the CronJobs it created, and translate them into reconciliations of the owning RutaProgramada. It is what makes deleting the CronJob by hand cause its recreation within seconds. Without that line, the operator would only react to changes in its own custom resources.

The +kubebuilder:rbac: markers above generate this ClusterRole:

Note the principle of least privilege: the operator can only touch CronJobs and its own resources. It cannot read Secrets, create Deployments or touch anything else. When you evaluate somebody else's operator (section 7), this is exactly what you should look at and compare against what the operator says it does. RBAC in detail is lesson 08-01.

make run is the practical advantage of this model: the controller runs on your laptop, with a debugger if you need one, talking to the real cluster. There is no need to build images for every iteration.

In lesson 02-02 we saw that a ReplicaSet puts ownerReferences on its pods, and that this is why deleting a Deployment deletes everything underneath. Operators use the same mechanism, and it is essential to understand it.

That line writes into the generated CronJob:

The consequences:

1. Automatic cascading deletion. When the RutaProgramada is deleted, Kubernetes' garbage collector deletes the CronJob. The operator does not have to write any clean-up code: the cluster itself takes care of it.
2. Ownership is visible. kubectl describe cronjob shows Controlled By: RutaProgramada/rn-041-bilbao-santander, which makes it traceable where each object came from.
3. Events towards the owner. Thanks to Owns(), changes to the CronJob trigger reconciliations of the route.

Two important restrictions:

• The owner and the owned object must be in the same namespace. A namespaced object cannot be owned by one from a different namespace.
• A cluster-scoped object cannot be owned by a namespaced one. If your operator creates ClusterRoles or PersistentVolumes, you will have to clean them up yourself.

When the operator creates external resources — a bucket, a DNS record, a database at a provider — ownerReferences are of no use: Kubernetes' garbage collector knows nothing about those resources.

That is what finalizers are for, the same mechanism we saw protecting PVCs in 05-03:

A first-order operational warning: if the operator stops working and there are objects carrying its finalizer, those objects stay in Terminating forever. kubectl delete hangs and there is no clean way out other than editing the object and removing the finalizer by hand:

That leaves the external resources orphaned, and they will have to be cleaned up some other way. It is one of the reasons behind the "what happens if I uninstall it?" question of section 7: always uninstall the operator after deleting its objects, never before.

Writing an operator is fun and almost always unnecessary. Before you start, put it through this filter.

A Deployment, a Service, a HorizontalPodAutoscaler and a ConfigMap cover bookings-api, web-store and notifications-worker completely. An operator would add nothing: the Deployment controller already does the reconciliation.

Operators shine with stateful software and complex operational procedures: databases, message queues, consensus systems, distributed stores. If your application restarts with no consequences, you do not need one.

The deciding question: "what has to happen when something breaks at three in the morning?" If the answer is "nothing, the Deployment recreates it", you do not need an operator. If it is "a replica has to be promoted, the routing reconfigured and somebody notified", then there is an operator there.

For PostgreSQL, MySQL, Redis, Kafka, MongoDB, Elasticsearch, RabbitMQ and practically any well-known software mature operators already exist, maintained by teams that have been at it for years. Writing your own means reimplementing, worse, what others have already solved, and maintaining it on your own.

What people underestimate:

• It is a production service with privileged permissions. It needs deployment, updates, monitoring, alerting and on-call.
• A failure in the operator affects everything it manages. A Reconcile with a bug can delete objects in cascade across the whole cluster. There are famous public incidents caused by this.
• CRDs are a public API with the compatibility obligations we saw in 06-06. Changing the schema afterwards is expensive.
• Testing an operator is hard. You need tests with envtest or an ephemeral cluster, and the reconciliation logic has many possible paths.
• It requires Go and deep Kubernetes knowledge in the team, in perpetuity, not just while it is being written.

A sensible rule of thumb:

Write an operator when you have a documented, repetitive operational procedure that runs often and that goes wrong when a tired human does it. If you cannot write that runbook precisely, you will not be able to encode it either.

The infinite reconciliation loop. Mistake number one: Reconcile writes to the API on every pass even when nothing has changed, the write generates an event, the event triggers another reconciliation. Symptom: thousands of updates per minute on the same object. Fix: compare before writing, with DeepDerivative or similar.

Keeping state in memory. Global variables, "already done it" maps. They are lost on restart and drift out of sync with the real world. All the state goes in .status, in annotations or in the managed objects.

Writing .status without the subresource. An Update of the whole object can overwrite a spec change the user has just made. Always use r.Status().Update() with the subresource enabled.

Forgetting ownerReferences. The objects created by the operator are left orphaned when the main resource is deleted. Over time the cluster fills with CronJobs, Services and Secrets nobody knows the origin of.

Uninstalling the operator before deleting its objects. If it uses finalizers, the objects stay in Terminating forever. The right order: delete the objects, check that they disappear, and only then uninstall the operator.

Adopting an operator that asks for cluster-admin. It is an open door to the whole cluster. Always review the ClusterRole before applying the manifest, and be suspicious of anyone asking for access to all Secrets without justifying it.

Confusing "it has CRDs" with "it is an operator". A CRD with no controller is a database with a form, as we saw in 06-06. Check that there is a Deployment running and that it writes to the objects' status.

Not reading the capability level. A level-2 operator is not going to save you from a night-time failover. If you adopt it believing it reaches level 5, the surprise will arrive at the worst moment.

Tip: use make run in development. The controller runs on your laptop against the real cluster, with a debugger. The iteration cycle goes from minutes to seconds.

Tip: emit events. r.Recorder.Eventf(...) makes the operator's actions show up in the object's kubectl describe. It is the difference between an operator you can diagnose and one that is a black box.

Tip: record observedGeneration. It lets anybody tell whether the controller has processed the latest spec change, and it is the basis for kubectl wait working reliably on your resources.

Tip: test by killing the controller. Delete it halfway through an operation and check that it picks up correctly when it comes back. If it does not, you have state in memory or you are missing idempotency.

On your minikube (profile rutas-norte), identify which operators are installed. For each one, work out: which CRDs it provides, where its controller runs, and what ClusterRole permissions it has. Then reason about why cert-manager is an operator while the Deployment controller, being the same pattern, is not called one.

Show experimentally that a controller reconciles continuously and a deployment does not:

1. Create a Deployment reconciliation-demo with 3 replicas in rutas-norte-dev.
2. Delete a pod and observe what happens and how quickly.
3. Manually change a pod's image with kubectl edit pod and observe the result.
4. Explain which controller acted in each case and with what information.

Rutas Norte wants an EntornoPruebas resource that, on being created, automatically brings about: a namespace of its own, a restore of bookings-postgres from the latest snapshot, a deployment of bookings-api pointing at that database, and complete deletion after 7 days.

Without writing any code, design:

1. The CRD's spec and status (fields and types).
2. The steps of the Reconcile function, in order.
3. The minimum RBAC permissions it would need.
4. What you would use for the deletion after 7 days, and why.
5. Whether a finalizer would be needed, and what for.

Solution 1

Narrow permissions: its own CRDs, plus Secrets (necessary: that is where it stores keys and certificates) and events. It does not ask for cluster-admin.

Why cert-manager is called an operator and the Deployment controller is not, given that they are the same pattern:

The difference is not technical, it is one of origin. Both are reconciliation loops over API types. The Deployment controller manages a native type and its code lives inside the kube-controller-manager, a control-plane binary. cert-manager manages types added through CRDs and runs as just another cluster workload.

The term "operator" designates that second situation: the controller pattern applied to a domain Kubernetes does not know about out of the box, packaged as a deployable application. Conceptually, the Deployment controller is a Deployment operator; it is simply that nobody calls it that because it comes included.

Solution 2

2. Delete a pod:

In less than a second there is a replacement. Nobody ran any command: the ReplicaSet saw there were 2 pods where there should be 3 and created one.

3. Change a pod's image by hand:

The change sticks. This is surprising, but it is correct and very instructive.

4. Which controller acted and with what information:

The key is what each controller reconciles:

• The ReplicaSet controller reconciles the number of pods matching its selector. It counts 2, it wants 3, it creates one. It does not care what image they run.
• The Deployment controller reconciles which ReplicaSets should exist according to the Deployment's template. Since the template did not change, it does nothing.
• Nobody reconciles the content of an individual pod against the Deployment's template. The template is used when creating the pod, not for watching it afterwards.

A practical lesson: reconciliation is about managed objects, not arbitrary fields. If you delete the modified pod, its replacement will be born from the template and will go back to nginx:1.27.2-alpine. And a kubectl rollout restart deployment/reconciliation-demo would recreate every pod from the template, correcting the drift.

Solution 3

1. CRD design:

The status subresource enabled. additionalPrinterColumns: Requester, Phase, Expiry, Age.

2. The steps of Reconcile:

1. Read the EntornoPruebas. If it does not exist, finish (IgnoreNotFound).
2. If it has a DeletionTimestamp, run the finalizer logic (step 10) and finish.
3. Make sure it has the finalizer if it does not already.
4. Check the expiry: if now() > status.expiryDate, delete the object itself and finish. The cascade will do the rest.
5. Make sure the namespace test-<name> exists with ownership labels. (It is a cluster-scoped object: it accepts no ownerReferences from a namespaced object; it is cleaned up in the finalizer.)
6. Make sure the PVC restored from the snapshot exists, with dataSource (05-05). If it is not Bound yet, update status.phase = "Restoring" and return RequeueAfter: 30s.
7. Make sure the PostgreSQL StatefulSet/Cluster and its generated credentials Secret exist.
8. Make sure the Deployments and Services for the components marked in spec.components exist, and the Ingress if appropriate.
9. Observe reality: are all the pods Ready? Write status.phase, accessUrl, conditions and observedGeneration through the subresource.
10. Return a calculated RequeueAfter: up to the expiry if it is far off, or 1 minute if it is close, so that step 4 fires in time.

3. Minimum RBAC:

Note what is not there: no cluster-admin, no permissions over nodes, none over RBAC. Secrets are unavoidable (it generates credentials), and that alone is reason enough to review the code before granting it those permissions.

4. The deletion after 7 days:

The right option is the reconciliation loop itself with RequeueAfter, not a clean-up CronJob:

• The operator is already watching the object: checking a date on every reconciliation is free.
• RequeueAfter guarantees it wakes up in time even if there is no other event.
• An external CronJob would be a second component with its own logic, its own permissions and its own way of failing, and it could be out of step with what the operator believes.
• Besides, ttlSecondsAfterFinished (06-03) does not apply: that is for Jobs, not for custom resources.

An implementation detail: the operator deletes its own object (r.Delete(ctx, &environment)), and the cascading deletion plus the finalizer take care of everything else. It is cleaner than deleting resources one by one.

5. A finalizer: yes, and it is essential.

The concrete reasons:

• The namespace is a cluster-scoped object from the point of view of the ownerReferences of an object living in another namespace: ownership cannot be established, so it has to be deleted explicitly.
• You have to verify that the PVC is released before declaring the deletion done, avoiding orphan volumes with the Retain class.
• There may be external resources: a DNS record test-xyz.rutasnorte.example, an entry in the internal billing system. Kubernetes' garbage collector knows about none of that.
• It is worth notifying the requester that their environment has expired before completing the deletion.

With the warning from section 9 firmly in mind: if the operator goes down with objects pending finalization, those objects stay in Terminating forever. That is why the finalizer must be fast, fault-tolerant and have a documented escape route.

An operator is a custom resource plus a controller that reconciles it: an expert's operational knowledge encoded in software that runs inside the cluster and never sleeps. Unlike a script or Helm, which act when somebody invokes them, an operator maintains the desired state continuously.

Its engine is the reconciliation loop of 01-02, now seen from the inside: a watch with a local cache, a work queue with deduplication and exponential backoff, and a Reconcile function that receives only a name and whose contract is always the same — read the desired, look at the real, bring them together — and that ends by writing the status through its subresource. Two non-negotiable properties: idempotency, because Reconcile will run many more times than you expect, and no state in memory, because the controller can restart at any moment.

The five-level model — install, upgrades, lifecycle, insights and auto pilot — is the tool for evaluating an operator before adopting it, along with the project's maintenance, the RBAC permissions it asks for and the decisive question of what happens if you uninstall it.

We have settled the debt we opened in 06-01: a PostgreSQL operator replaces our hand-rolled StatefulSet and provides what a StatefulSet can never give on its own — primary election, automatic failover in seconds, read replicas, -rw and -ro Services that rewrite themselves, scheduled backups and point-in-time recovery — with a YAML instead of weeks of work and night shifts. And we have sketched the RutaProgramada controller with Kubebuilder: the markers that generate the CRD and the RBAC, the seven steps of Reconcile, ownerReferences for cascading deletion and finalizers for whatever lives outside the cluster.

And we have ended up where we had to: most teams should not write operators. For stateless applications they add nothing, for well-known software they already exist and are better than the one you would write, and maintaining one means operating a privileged service in perpetuity. Write one only when you have a repetitive, documented procedure that goes wrong at three in the morning.

This lesson closes the advanced concepts module. The Rutas Norte platform has changed a great deal:

It is a powerful platform. And it is, right now, completely opaque.

There is no way of knowing whether bookings-api is healthy, beyond its pod saying Running — which only means the process started, not that it works. We do not know how much memory bookings-postgres really uses or whether the 2 GiB we reserved for it in 03-05 is too much or too little. If the reports CronJob failed last night at three in the morning, the only clue is some logs that will be deleted along with the history. If web-store starts answering in three seconds instead of a hundred milliseconds, we will find out from a complaint by a customer who could not buy their ticket.

Everything we have built is flying blind. That ends in module 7: Monitoring and Logging. We will start with the most basic and most important thing — teaching Kubernetes to tell a container that started from one that works — with the health checks and probes of lesson 07-01.