Σκοπός αυτού του φύλλου ασκήσεων

Αυτό το φύλλο συμπληρώνει το εργαστήριο Professional με εργασίες προσανατολισμένες στην παραγωγή. Εστιάζει στο platform blueprint, στο μοντέλο λειτουργίας, στη σύγκριση managed/self-managed/hybrid, στα Node Pools, στο Cluster Sizing, στα upgrades, στα API deprecations, στο observability, στο autoscaling, στο GitOps, στο multi-tenancy, στους Operators, στα CRDs, στα backup, στο disaster recovery, στη διαχείριση κόστους και στα runbooks.

Εδώ το επίπεδο Professional σημαίνει ότι δεν αποδεικνύεις απλώς πως εκτελείται μια εφαρμογή. Ορίζεις πώς λειτουργεί, αναβαθμίζεται, παρακολουθείται, κλιμακώνεται και επαναφέρεται μια πλατφόρμα για πολλές ομάδες, με επίγνωση του κόστους.

Προϋποθέσεις

Χρειάζεσαι:

• ένα lab cluster ή προσομοιωμένα cluster contexts,
• kubectl,
• προαιρετικά Helm και Kustomize,
• προαιρετικά Metrics Server, Prometheus/Grafana ή έτοιμο περιβάλλον observability,
• προαιρετικά GitOps Controllers όπως Argo CD ή Flux,
• προαιρετικά Velero ή επίδειξη backup.

Προτεινόμενος κατάλογος εργασίας:

kubernetes/professional-exercises/
  platform-blueprint.md
  upgrade-runbook.md
  observability-slo.md
  autoscaling-review.md
  gitops-flow.md
  tenant-template/
  operator-review.md
  dr-runbook.md
  cost-review.md

Επισκόπηση ασκήσεων

Μέρος Α – Ασκήσεις

Άσκηση 1: Δημιουργία platform blueprint

Στόχος

Περιγράφεις ένα επαναλήψιμο πρότυπο για Kubernetes cluster προσανατολισμένο στην παραγωγή.

Εργασία

Δημιούργησε το platform-blueprint.md με τις εξής ενότητες:

1. Στόχος της πλατφόρμας.
2. Μοντέλο cluster: κοινό cluster ή cluster ανά περιβάλλον.
3. Διαχωρισμός περιβαλλόντων: dev, test, stage, prod.
4. Αρμοδιότητες: platform team, application team, security και operations.
5. Βασικά add-ons: CNI, CSI, CoreDNS, Ingress/Gateway, metrics, observability, GitOps και backup.
6. Πρότυπο Namespace: Labels, owner, RBAC, Quotas, LimitRanges, NetworkPolicy και Pod Security.
7. Διαδικασία upgrades και deprecations.
8. Μοντέλο observability και SLO.
9. Μοντέλο backup και restore.
10. Μοντέλο κόστους: showback ή chargeback.

Αναμενόμενο αποτέλεσμα

Ένα δεύτερο άτομο μπορεί, με βάση το blueprint, να κατανοήσει πώς πρέπει να δημιουργηθεί και να λειτουργεί ένα νέο cluster.

Άσκηση 2: Αξιολόγηση managed, self-managed και hybrid

Στόχος

Λαμβάνεις μια τεκμηριωμένη απόφαση για την πλατφόρμα και καταγράφεις τα πλεονεκτήματα και τα μειονεκτήματα κάθε επιλογής.

Εργασία

Δημιούργησε πίνακα αποφάσεων για τρία σενάρια:

1. Managed Kubernetes για τυπικές web εφαρμογές.
2. Self-managed Kubernetes για ιδιαίτερα εξειδικευμένα bare-metal workloads.
3. Hybrid μοντέλο για components στο cloud και σε on-premises περιβάλλον.

Αξιολόγησε:

• την ευθύνη για το Control Plane,
• την προσπάθεια για upgrades,
• την ευθύνη ασφάλειας,
• το κόστος και την εξάρτηση από τον πάροχο,
• τον λειτουργικό κίνδυνο,
• τις δεξιότητες που χρειάζεται η ομάδα.

Άσκηση 3: Σχεδιασμός Node Pools και Cluster Sizing

Στόχος

Σχεδιάζεις Node Pools, εφεδρική χωρητικότητα και πόρους για add-ons σε μια πλατφόρμα προσανατολισμένη στην παραγωγή.

Σενάριο

Η πλατφόρμα πρέπει να φιλοξενεί:

• 20 τυπικές web υπηρεσίες,
• 5 workers με υψηλές απαιτήσεις CPU,
• 3 stateful υπηρεσίες με PVC,
• ένα observability stack,
• έναν Ingress/Gateway Controller,
• έναν GitOps Controller,
• έναν backup controller.

Εργασία

1. Σχεδίασε τουλάχιστον τρία Node Pools.
2. Υπολόγισε την επιβάρυνση από το σύστημα και τα add-ons.
3. Όρισε εφεδρική χωρητικότητα για rollouts και αστοχίες Nodes.
4. Κατάγραψε τα cloud provider quotas που πρέπει να ελεγχθούν.
5. Σύνταξε κριτήρια διακοπής για την κλιμάκωση.

Άσκηση 4: Σύνταξη upgrade runbook με έλεγχο API deprecations

Στόχος

Σχεδιάζεις ένα Kubernetes minor upgrade ως ελεγχόμενη αλλαγή με διαδρομή επικύρωσης και rollback.

Εργασία

Δημιούργησε το upgrade-runbook.md με:

1. τρέχουσα έκδοση και έκδοση στόχο,
2. έλεγχο version skew,
3. έλεγχο API deprecations,
4. έλεγχο CRDs και webhooks,
5. συμβατότητα add-ons,
6. backup και σημείο restore,
7. test cluster ή staging,
8. upgrade του Control Plane,
9. έλεγχο add-ons,
10. upgrade των Node Pools με cordon και drain,
11. smoke tests,
12. κριτήρια διακοπής,
13. σχέδιο rollback ή ανάκαμψης,
14. τελική αναφορά.

Άσκηση 5: Ορισμός μοντέλου observability και SLO

Στόχος

Περιγράφεις το observability ως μοντέλο λειτουργίας με σήματα, SLOs, alerts και runbooks, όχι απλώς ως κατάλογο εργαλείων.

Εργασία

Για μια ενδεικτική εφαρμογή checkout-api όρισε:

• Service Level Objective,
• Service Level Indicator,
• metrics,
• logs,
• traces,
• Kubernetes Events,
• dashboards,
• alerts,
• σύνδεσμο προς runbook,
• χρόνο διατήρησης δεδομένων.

Πρόσθεσε επίσης σήματα πλατφόρμας για API Server, CoreDNS, Ingress, Nodes και PVCs.

Άσκηση 6: Αξιολόγηση autoscaling

Στόχος

Κατατάσσεις HPA, VPA, Cluster Autoscaler, Karpenter και KEDA ανά σκοπό, προϋποθέσεις και κίνδυνο.

Σενάριο

Μια εφαρμογή workers επεξεργάζεται εργασίες από ουρά, με ακανόνιστο ρυθμό. Κατά τη διάρκεια της ημέρας υπάρχουν αιχμές φορτίου. Τη νύχτα η πλατφόρμα πρέπει να μειώνει το κόστος.

Εργασία

1. Όρισε CPU και memory requests.
2. Σχεδίασε στρατηγική HPA.
3. Αποφάσισε αν είναι χρήσιμο το KEDA.
4. Περιέγραψε την αλληλεπίδραση με το Node autoscaling.
5. Κατάγραψε κινδύνους όπως ταλαντώσεις, αύξηση κόστους και ελλιπή metrics.

Άσκηση 7: Σχεδίαση ροής GitOps και CI/CD

Στόχος

Διαχωρίζεις καθαρά το CI από το GitOps και αποφεύγεις μόνιμα εκτεταμένα δικαιώματα cluster για το CI pipeline.

Εργασία

Δημιούργησε το gitops-flow.md με τη ροή:

1. commit του κώδικα,
2. CI: build, test, scan,
3. push του image στο registry,
4. προσδιορισμός digest,
5. pull request για αλλαγή στο manifest,
6. review και έγκριση,
7. GitOps sync,
8. ανίχνευση drift,
9. rollback μέσω Git revert.

Τεκμηρίωσε ποια identity χρειάζεται ποια δικαιώματα.

Άσκηση 8: Δημιουργία προτύπου Namespace για πολλούς tenants

Στόχος

Δημιουργείς πρότυπο Namespace για μια ομάδα που μπορεί να κάνει deploy με περιορισμένα δικαιώματα χωρίς πρόσβαση σε ολόκληρο το cluster.

Εργασία

Δημιούργησε manifests για:

• Namespace με Labels,
• ResourceQuota,
• LimitRange,
• Role,
• RoleBinding,
• NetworkPolicy Default Deny,
• Pod Security Labels,
• owner annotation.

Τεκμηρίωσε ποιοι έλεγχοι προετοιμάζονται μόνο στο επίπεδο Professional και εφαρμόζονται αυστηρότερα στο Advanced.

Άσκηση 9: Αξιολόγηση Operator και CRD

Στόχος

Εξετάζεις αν ένας Operator μπορεί να λειτουργεί αξιόπιστα στην πλατφόρμα.

Εργασία

Επίλεξε έναν υποθετικό Operator database-operator και τεκμηρίωσε:

1. τα εγκατεστημένα CRDs,
2. τα απαιτούμενα ClusterRoles,
3. τα Custom Resources που διαχειρίζεται,
4. τα Conditions και Events,
5. τη σημασία του για τα backup,
6. τους κινδύνους upgrade,
7. τους κινδύνους απεγκατάστασης,
8. τη δυνατότητα multi-tenancy,
9. τα κριτήρια διακοπής πριν από τη χρήση σε παραγωγή.

Άσκηση 10: Σχεδιασμός backup και disaster recovery

Στόχος

Διακρίνεις την κατάσταση Git, το etcd, τα δεδομένα PVC, τα Secrets, τα CRDs και τα εξωτερικά συστήματα.

Εργασία

Δημιούργησε το dr-runbook.md με δύο σενάρια:

1. Restore ενός μεμονωμένου Namespace.
2. Restore ολόκληρου cluster.

Για κάθε σενάριο περιέγραψε:

• τις κατηγορίες δεδομένων που επηρεάζονται,
• τα απαιτούμενα backups,
• τη σειρά restore,
• την επικύρωση,
• τις παραδοχές RTO/RPO,
• τους κινδύνους,
• τα τεκμήρια.

Άσκηση 11: Ανάλυση κόστους και rightsizing

Στόχος

Αναλύεις τους παράγοντες κόστους και προτείνεις τεχνικές ενέργειες rightsizing.

Σενάριο

Ένα cluster εμφανίζει:

• πολλά Pods με υψηλά requests και χαμηλή πραγματική χρήση,
• αρκετά αχρησιμοποίητα PVCs,
• αρκετούς εξωτερικούς Load Balancers,
• dev workloads που εκτελούνται συνεχώς,
• καμία αντιστοίχιση showback ανά Namespace.

Εργασία

Δημιούργησε το cost-review.md με:

• πηγές κόστους,
• τεχνικά σημεία μέτρησης,
• προτάσεις rightsizing,
• κινδύνους από ανεπαρκή requests,
• μοντέλο showback,
• σχέδιο ενεργειών.

Άσκηση 12: Προετοιμασία παράδοσης της λειτουργίας

Στόχος

Δημιουργείς ένα έγγραφο παράδοσης που μπορεί να χρησιμοποιήσει άλλο άτομο σε βάρδια on-call ή κατά τη λειτουργία της πλατφόρμας.

Εργασία

Σύνταξε σύντομη παράδοση με:

• επισκόπηση πλατφόρμας,
• κρίσιμα add-ons,
• γνωστά SLOs,
• διαδρομές alerting,
• παράθυρα upgrades,
• ευθύνη για backup και restore,
• τα 5 σημαντικότερα runbooks,
• κριτήρια διακοπής,
• ανοιχτούς κινδύνους.

Μέρος Β – Ενδεικτικές λύσεις και αναλυτική καθοδήγηση

Λύση 1: Platform blueprint

Ενδεικτική δομή:

# Platform Blueprint

## 1. Στόχος

Η πλατφόρμα παρέχει τυποποιημένα περιβάλλοντα Kubernetes για πολλές ομάδες εφαρμογών. Προσφέρει ασφαλή Namespaces, deployments μέσω GitOps, κεντρικό observability, Ingress/Gateway, storage, backup και τεκμηριωμένες διαδικασίες upgrade.

## 2. Μοντέλο cluster

- Dev/test: κοινό cluster με απομόνωση μέσω Namespaces.
- Stage/prod: χωριστά clusters ανάλογα με την κρισιμότητα ή το περιβάλλον.
- Clusters παραγωγής σε τουλάχιστον τρεις Availability Zones.

## 3. Αρμοδιότητες

| Πεδίο | Υπεύθυνος |
| --- | --- |
| Control Plane | πάροχος ή platform team |
| Nodes και Node Pools | platform team |
| CNI/CSI/CoreDNS | platform team |
| Περιεχόμενο Namespace | application team |
| Πολιτικές ασφάλειας | platform team και security |
| SLOs εφαρμογών | application team |
| SLOs πλατφόρμας | platform team |

## 4. Βασικά add-ons

| Add-on | Σκοπός | Υπεύθυνος | SLO |
| --- | --- | --- | --- |
| CNI | δίκτυο Pods και NetworkPolicy | platform | διαθεσιμότητα δικτύου Pods |
| CSI | δημιουργία PV | platform | αξιόπιστη δημιουργία PVC |
| CoreDNS | service discovery | platform | καθυστέρηση DNS και ποσοστό σφαλμάτων |
| Ingress/Gateway | εξωτερική πρόσβαση HTTP | platform | διαθεσιμότητα routing 99,9% |
| Observability | metrics/logs/traces/Events | platform | διαθεσιμότητα σημάτων |
| GitOps | συγχρονισμός επιθυμητής κατάστασης | platform | αξιόπιστος συγχρονισμός |
| Backup | δυνατότητα restore | platform | δοκιμασμένο restore |

## 5. Πρότυπο Namespace

Κάθε Namespace ενός tenant λαμβάνει:

- Labels υπευθύνου,
- ResourceQuota,
- LimitRange,
- Role/RoleBinding,
- NetworkPolicy Default Deny,
- Pod Security Labels,
- Label κόστους.

## 6. Κύκλος ζωής

- μηνιαίος έλεγχος deprecations,
- τριμηνιαίο παράθυρο για Kubernetes minor upgrade,
- δοκιμή στο staging πριν από το prod,
- τεκμηριωμένα κριτήρια διακοπής,
- smoke tests μετά από κάθε βήμα upgrade.

Αξιολόγηση:

Ένα καλό blueprint δεν εξαρτάται από ένα συγκεκριμένο εργαλείο. Περιγράφει υπευθύνους, SLOs, διαδρομές upgrade, απομόνωση, κόστος και ανάκαμψη.

Λύση 2: Managed, self-managed και hybrid

Ενδεικτικός πίνακας αποφάσεων:

Ενδεικτική αξιολόγηση:

• Το managed Kubernetes αποτελεί συνήθως την προεπιλογή για web εφαρμογές, εφόσον τα όρια του παρόχου είναι αποδεκτά.
• Το self-managed είναι χρήσιμο μόνο όταν ειδικές απαιτήσεις δικαιολογούν την πρόσθετη πολυπλοκότητα.
• Το hybrid δεν είναι συμβιβασμός χωρίς κόστος: αυξάνει τις απαιτήσεις διακυβέρνησης, δικτύωσης και λειτουργίας.

Λύση 3: Node Pools και sizing

Ενδεικτικά Node Pools:

Λίστα ελέγχου sizing:

• Άθροισε τα requests των εφαρμογών και την επιβάρυνση των DaemonSets.
• Πρόβλεψε χώρο για rolling updates: χρειάζεται επιπλέον χωρητικότητα για νέα Pods κατά το rollout.
• Πρόβλεψε χώρο για αστοχία ζώνης ή Node, ανάλογα με το SLA.
• Μη λειτουργείς CoreDNS, logging, metrics και Ingress με τις ελάχιστες τιμές που αρκούν μόνο για μικρά clusters.
• Έλεγξε cloud quotas για compute, IPs, volumes, Load Balancers, firewall rules και egress.

Κριτήρια διακοπής:

• Ο Cluster Autoscaler δεν μπορεί πλέον να προσθέσει Nodes.
• Ο διαθέσιμος χώρος διευθύνσεων IP εξαντλήθηκε.
• Το CoreDNS ή το CNI εμφανίζει υψηλό ποσοστό σφαλμάτων.
• Τα Pods παραμένουν σε κατάσταση Pending λόγω έλλειψης πόρων.
• Τα add-ons παρουσιάζουν OOMKill ή CPU throttling.

Λύση 4: Upgrade runbook

Ενδεικτικό περιεχόμενο:

# Upgrade Runbook

## Στόχος

Upgrade από Kubernetes v1.x σε v1.y.

## Έλεγχος πριν από το upgrade

- kubectl version
- kubectl get nodes -o wide
- kubectl get pods -A
- kubectl get apiservices
- kubectl get crds
- kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations

## Έλεγχος API deprecations

- Αναζήτησε παλαιά API versions σε Git repositories.
- Κάνε render και έλεγχο στα Helm charts.
- Κάνε render και έλεγχο στα Kustomize overlays.
- Έλεγξε τις εκδόσεις CRD και τα conversion webhooks.

## Backup

- Backup του etcd ή snapshot του παρόχου.
- Backup Velero/Namespace, εφόσον είναι διαθέσιμο.
- PV snapshots για stateful workloads.
- Καταγραφή της έκδοσης του GitOps repository.

## Ακολουθία

1. Ανακοίνωσε την αλλαγή.
2. Δοκίμασε στο staging.
3. Αναβάθμισε το Control Plane.
4. Επικύρωσε τα add-ons.
5. Αναβάθμισε τα Node Pools ένα προς ένα.
6. Για κάθε Node: cordon, drain, upgrade, uncordon.
7. Εκτέλεσε smoke tests.
8. Σύνταξε τελική αναφορά.

## Κριτήρια διακοπής

- Αυξήθηκε το ποσοστό σφαλμάτων του API Server.
- Το CoreDNS δεν είναι σταθερό.
- Το CNI/CSI δεν είναι συμβατό.
- Κρίσιμα workloads δεν βρίσκονται σε κατάσταση Ready.
- Ένα webhook εμποδίζει τα deployments.
- Ένα εύρημα deprecation δεν έχει διορθωθεί.

Ενδεικτικές εντολές:

kubectl api-resources
kubectl api-versions
kubectl get apiservices
kubectl get crds
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl uncordon <node>

Λύση 5: Observability και SLO

Ενδεικτικό SLO:

# Observability SLO checkout-api

## SLO

Το 99,9% των HTTP requests προς το `/checkout` ολοκληρώνεται επιτυχώς μέσα σε 300 ms, σε κυλιόμενο διάστημα 30 ημερών.

## SLI

- Ποσοστό επιτυχίας: HTTP 2xx/3xx διαιρεμένα με όλα τα requests, εξαιρώντας τα 4xx που έχουν αποκλειστεί ρητά.
- Καθυστέρηση: διάρκεια request στο p95.

## Σήματα

| Σήμα | Πηγή | Σκοπός |
| --- | --- | --- |
| Ρυθμός requests | Ingress/app metrics | προφίλ φορτίου |
| Ποσοστό σφαλμάτων | app/Ingress metrics | διαθεσιμότητα |
| Διάρκεια p95/p99 | app/Ingress metrics | καθυστέρηση |
| Logs | app logs | ανάλυση βασικής αιτίας |
| Traces | OpenTelemetry | ανάλυση εξαρτήσεων |
| Events | Kubernetes API | scheduling, probes, image pulls, PVC |
| Χρήση πόρων | cAdvisor/kubelet | CPU, μνήμη και throttling |

## Alerts

- Ποσοστό σφαλμάτων > 2% για 10 λεπτά.
- p95 > 300 ms για 15 λεπτά.
- Το Deployment δεν είναι πλήρως διαθέσιμο για 10 λεπτά.
- Το HPA βρίσκεται στο μέγιστο για 15 λεπτά.

## Runbooks

- checkout-api-high-error-rate.md
- checkout-api-latency.md
- checkout-api-rollout-failure.md

Σήματα πλατφόρμας:

Λύση 6: Autoscaling

Ενδεικτική αξιολόγηση:

Ενδεικτικό HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker
  namespace: worker-prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker
  minReplicas: 2
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

Ενδεικτική απόφαση:

Για φορτίο που προέρχεται από ουρά, το KEDA είναι συχνά τεχνικά καταλληλότερο από την κλιμάκωση μόνο βάσει CPU, επειδή το μήκος της ουράς αποτυπώνει πιο άμεσα τις εκκρεμείς εργασίες. Το HPA μπορεί να το συμπληρώνει όταν η χρήση CPU διαφέρει σημαντικά από εργασία σε εργασία.

Λύση 7: GitOps και CI/CD

Ενδεικτική ροή:

Commit κώδικα
  -> Το CI δημιουργεί το image
  -> Το CI εκτελεί tests και scan
  -> Το CI προωθεί το image στο registry
  -> Το CI προσδιορίζει το image digest
  -> Το CI δημιουργεί pull request στο repository των manifests
  -> Το review ελέγχει manifest, πολιτική και diff
  -> Το merge ενημερώνει την επιθυμητή κατάσταση
  -> Ο GitOps Controller συγχρονίζει το cluster
  -> Το Drift Detection αναφέρει αποκλίσεις
  -> Το rollback γίνεται μέσω Git Revert

Δικαιώματα:

Κριτήριο διακοπής:

Το CI pipeline δεν λαμβάνει μόνιμα δικαιώματα cluster-admin. Η κατάσταση του cluster συγχρονίζεται μέσω GitOps και όχι μέσω επιτακτικών deployments από το CI.

Λύση 8: Namespace για πολλούς tenants

Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  labels:
    owner: team-a
    environment: prod
    cost-center: cc-1234
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
  annotations:
    platform.example.com/owner-email: team-a@example.com

ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    pods: "20"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    persistentvolumeclaims: "5"

LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-defaults
  namespace: team-a
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi

Role και RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: team-a
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["pods", "services", "configmaps", "deployments", "replicasets", "jobs", "cronjobs", "ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-deployer-binding
  namespace: team-a
subjects:
  - kind: Group
    name: team-a-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: app-deployer
  apiGroup: rbac.authorization.k8s.io

NetworkPolicy Default Deny:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Όριο του επιπέδου Professional:

• Το Professional σχεδιάζει τη διακυβέρνηση των tenants.
• Το Advanced + Security εξετάζει διεξοδικά διαδρομές κλιμάκωσης προνομίων στο RBAC, την επιβολή μέσω Admission, τα Secrets, το threat model και το incident response.

Λύση 9: Αξιολόγηση Operator

Ενδεικτική αξιολόγηση:

# Αξιολόγηση Operator: database-operator

## Σκοπός

Αυτοματοποιεί database instances μέσω Custom Resources.

## CRDs

- databases.example.com
- databasebackups.example.com
- databaserestores.example.com

## Δικαιώματα

Ο Operator χρειάζεται πρόσβαση σε StatefulSets, Services, Secrets, PVCs, Events και στα δικά του CRDs. Τα δικαιώματα σε ολόκληρο το cluster πρέπει να αιτιολογούνται.

## Conditions

- Ready
- Progressing
- Degraded
- BackupReady
- RestoreFailed

## Backup

Τα Custom Resources από μόνα τους δεν αρκούν. Πρέπει να συμπεριληφθούν τα δεδομένα PVC, τα Secrets και τα εξωτερικά backups.

## Κίνδυνοι upgrade

- αλλαγές στο schema των CRDs,
- conversion webhooks,
- finalizers που εμποδίζουν τη διαγραφή,
- ασύμβατο image του Operator,
- παλαιά Custom Resources που δεν μπορούν να μεταφερθούν.

## Κριτήρια διακοπής

- ασαφές ClusterRole με `*`,
- απουσία τεκμηριωμένης δοκιμής restore,
- απουσία στρατηγικής versioning για τα CRDs,
- απουσία οδηγού απεγκατάστασης,
- απουσία δυνατότητας multi-tenancy.

Λύση 10: Backup και disaster recovery

Restore Namespace:

# Restore Namespace

## Κατηγορίες δεδομένων

- manifests από το Git,
- Secrets από το σύστημα διαχείρισης μυστικών,
- δεδομένα PVC από VolumeSnapshot ή backup,
- CRDs, εφόσον το Namespace περιέχει Custom Resources.

## Σειρά

1. Δημιούργησε το Namespace στόχου.
2. Εφάρμοσε Quotas, RBAC και Policies.
3. Επανάφερε τα Secrets.
4. Επανάφερε PVCs ή VolumeSnapshots.
5. Συγχρόνισε τα workloads μέσω GitOps.
6. Έλεγξε τις διαδρομές Service και Ingress/Gateway.
7. Εκτέλεσε smoke tests.

## Τεκμήρια

- χρονική στιγμή του restore,
- Git revision,
- backup ID,
- επιτυχημένα smoke tests,
- ανοιχτές αποκλίσεις.

Restore cluster:

# Restore Cluster

## Κατηγορίες δεδομένων

- add-ons του cluster,
- CRDs,
- Namespaces,
- RBAC,
- Secrets,
- δεδομένα PV/PVC,
- εξωτερικά συστήματα: DNS, registry και identity provider.

## Σειρά

1. Δημιούργησε νέο cluster ή εκτέλεσε restore του etcd.
2. Επικύρωσε CNI, CSI και CoreDNS.
3. Εγκατάστησε τα CRDs.
4. Εγκατάστησε τον GitOps Controller.
5. Συγχρόνισε τα Namespaces της πλατφόρμας.
6. Συγχρόνισε τα Namespaces των tenants.
7. Επανάφερε τα δεδομένα PV.
8. Επικύρωσε Ingress και DNS.
9. Εκτέλεσε smoke tests για τα SLOs.

Βασικός κανόνας:

Ένα backup θεωρείται αξιόπιστο μόνο αφού πραγματοποιηθεί και τεκμηριωθεί δοκιμή restore.

Λύση 11: Ανάλυση κόστους και rightsizing

Ενδεικτική ανάλυση:

Ενδεικτικό showback:

Κάθε Namespace χρειάζεται Labels:

metadata:
  labels:
    owner: team-a
    cost-center: cc-1234
    environment: prod

Κίνδυνος από ανεπαρκή requests:

Τα πολύ χαμηλά requests φαίνεται να εξοικονομούν χρήματα, αλλά μπορούν να επηρεάσουν αρνητικά το scheduling, το HPA, τη χρήση Nodes και τη σταθερότητα. Rightsizing δεν σημαίνει «όρισε τα requests στο ελάχιστο»· σημαίνει επιλογή ρεαλιστικών λειτουργικών τιμών.

Λύση 12: Παράδοση λειτουργίας

Ενδεικτικό έγγραφο παράδοσης:

# Παράδοση λειτουργίας της πλατφόρμας Kubernetes

## Επισκόπηση

- Cluster: prod-eu-1.
- Μοντέλο: Managed Kubernetes.
- Περιβάλλοντα: χωριστά stage/prod.
- GitOps: Argo CD.
- Ingress: Gateway Controller.
- Observability: Prometheus, Grafana, Loki, OpenTelemetry.

## Κρίσιμα add-ons

| Add-on | Υπεύθυνος | Runbook |
| --- | --- | --- |
| CoreDNS | platform | runbooks/coredns.md |
| CNI | platform | runbooks/network.md |
| CSI | platform | runbooks/storage.md |
| GitOps | platform | runbooks/gitops.md |
| Ingress/Gateway | platform | runbooks/ingress.md |

## Κριτήρια διακοπής

- Ο API Server δεν είναι προσβάσιμος.
- Το CoreDNS παρουσιάζει κρίσιμο ποσοστό σφαλμάτων.
- Το CNI εμποδίζει τη δικτύωση των Pods.
- Το CSI δεν μπορεί να συνδέσει volumes.
- Το GitOps συγχρονίζει λανθασμένη επιθυμητή κατάσταση.

## Ανοιχτοί κίνδυνοι

- Η τελευταία δοκιμή restore του cluster έγινε πριν από περισσότερες από 90 ημέρες.
- Ορισμένα Namespaces δεν έχουν Label κόστους.
- Βρέθηκαν δύο παλαιά API versions σε legacy chart.

Λίστα ελέγχου αξιολόγησης