# Platform Blueprint

## Στόχος

Η πλατφόρμα Kubernetes παρέχει τυποποιημένα περιβάλλοντα για 12 ομάδες προϊόντων και 40 έως 60 microservices. Πρέπει να υποστηρίζει upgrades, observability, πολλούς tenants, ανάκαμψη και έλεγχο κόστους.

## Μοντέλο cluster

| Περιβάλλον | Μοντέλο | Αιτιολόγηση |
| --- | --- | --- |
| dev | κοινό cluster | κόστος, γρήγορες επαναλήψεις, χαμηλότερη κρισιμότητα |
| staging | αποκλειστικό cluster | εγγύτητα στην παραγωγή, δοκιμές upgrades και releases |
| production | αποκλειστικό cluster, προαιρετικά διαχωρισμένο ανά κρισιμότητα | blast radius, συμμόρφωση, σταθερά παράθυρα συντήρησης |

## Availability Zones

Η παραγωγή λειτουργεί σε τουλάχιστον τρεις Availability Zones. Τα add-ons του συστήματος και τα replicas των εφαρμογών κατανέμονται μεταξύ ζωνών. Τα stateful workloads χρησιμοποιούν StorageClasses με κατάλληλη δέσμευση ζώνης και τεκμηριωμένη στρατηγική restore.

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

| Πεδίο | Υπεύθυνος | Εργασίες |
| --- | --- | --- |
| Platform team | platform | clusters, Node Pools, add-ons, GitOps, Quotas, runbooks |
| Application teams | ομάδες προϊόντων | manifests εφαρμογών, SLOs, Requests, probes, λειτουργικά releases |
| Security | ομάδα security | πολιτικές, audits, διαδικασίες εξαιρέσεων, τεκμήρια συμμόρφωσης |
| Operations/on-call | platform και εφαρμογές | αρχική απόκριση σε incident, escalation, ασκήσεις disaster recovery |

## Ingress/Gateway

- Κεντρικός Gateway ή Ingress Controller ανά περιβάλλον.
- Οι ομάδες εφαρμογών ζητούν hostnames και routes μέσω PR.
- Τα TLS certificates διαχειρίζονται μέσω cert-manager ή εσωτερικού μοντέλου πιστοποιητικών.
- Wildcard certificates μόνο με τεκμηριωμένη έγκριση.

## DNS και πιστοποιητικά

- Τα εξωτερικά DNS records συντηρούνται αυτόματα ή μέσω διαδικασίας αλλαγής.
- Τα πιστοποιητικά έχουν υπευθύνους, παρακολούθηση λήξης και διαδικασία ανανέωσης.
- Η παραγωγή χρησιμοποιεί ξεχωριστούς issuers ή πολιτικές PKI.

## Storage και backup

- Προεπιλεγμένη StorageClass για γενικά PVCs.
- Ξεχωριστή StorageClass για stateful ή ρυθμιζόμενα workloads.
- VolumeSnapshots ή εργαλείο backup για δεδομένα PVC.
- Δοκιμές restore τουλάχιστον κάθε τρίμηνο.

## GitOps

- Το Git αποτελεί την πηγή της επιθυμητής κατάστασης.
- Το CI δημιουργεί images και PRs για manifests με digests.
- Ο GitOps Controller συγχρονίζει τα Namespaces στόχου με περιορισμένα δικαιώματα.
- Το rollback γίνεται μέσω Git revert.

## Observability

- Metrics, logs, traces και Kubernetes Events συλλέγονται κεντρικά.
- Τα SLOs της πλατφόρμας και των εφαρμογών τεκμηριώνονται.
- Τα alerts παραπέμπουν σε runbooks.
- Ο χρόνος διατήρησης ορίζεται ανά περιβάλλον και απαίτηση συμμόρφωσης.

## Labels κόστους και showback

Απαιτούμενα Labels:

- `owner`
- `environment`
- `cost-center`
- `app`

Το showback αξιολογείται ανά Namespace, ομάδα, περιβάλλον και πηγή κόστους.

# Μοντέλο λειτουργίας

## Σύσταση

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

## Πίνακας αποφάσεων

| Κριτήριο | Managed | Self-managed | Hybrid |
| --- | --- | --- | --- |
| Control Plane | λειτουργεί από τον πάροχο | λειτουργεί από εσωτερική ομάδα | κατανεμημένη ευθύνη |
| Προσπάθεια upgrade | μικρότερη, αλλά τα add-ons παραμένουν εσωτερική ευθύνη | μεγάλη | μέτρια έως μεγάλη |
| Ευθύνη ασφάλειας | μοιρασμένη | κυρίως εσωτερική | μοιρασμένη και σύνθετη |
| Εξάρτηση από πάροχο | μεγάλη | μικρή έως μέτρια | μέτρια |
| Λειτουργικός κίνδυνος | όρια και αφαιρέσεις του παρόχου | λειτουργικά σφάλματα, PKI/etcd/HA | σφάλματα ενσωμάτωσης |
| Δυνατότητες ομάδας | γνώση πλατφόρμας και cloud | βαθιά γνώση Kubernetes/etcd/PKI | cloud, on-prem και δίκτυο |
| Μοντέλο κόστους | προβλέψιμο, χρεώσεις παρόχου | προσωπικό λειτουργίας και υποδομή | σύνθετο μοντέλο |

## Ανοιχτές αποφάσεις

- Διαχωρισμός ρυθμιζόμενων δεδομένων παραγωγής ανά cluster ή ανά Namespace με πρόσθετους ελέγχους.
- Επιλογή Gateway API ή Ingress.
- Επιλογή εργαλείου backup και συχνότητας δοκιμών restore.
- Επιλογή Policy Engine και διαδικασίας εξαιρέσεων.

# Sizing των Node Pools

| Node Pool | Σκοπός | Χαρακτηριστικά | Κίνδυνοι |
| --- | --- | --- | --- |
| system-pool | add-ons πλατφόρμας | taints, σταθερά on-demand Nodes, προγραμματισμένη επιβάρυνση | αστοχία add-on εμποδίζει την πλατφόρμα |
| app-general | τυπικές web υπηρεσίες | κατανομή μεταξύ ζωνών, δυνατότητα HPA, εφεδρική χωρητικότητα για rolling updates | υπερβολικά Requests, πυκνότητα Pods |
| worker-cpu | workers με υψηλές απαιτήσεις CPU | autoscaling, προαιρετικά Spot με retry/PDB | διακοπές Spot, διακύμανση κόστους |
| stateful | workloads κοντά σε PVC | σταθερή σύνδεση storage, προσεκτική συντήρηση | δέσμευση ζώνης, σύνθετο restore |

## Κανόνες sizing

- Υπολόγισε τα Requests των εφαρμογών μαζί με την επιβάρυνση των DaemonSets.
- Συνυπολόγισε τα `kube-reserved` και `system-reserved`.
- Πρόβλεψε επιπλέον χωρητικότητα για νέα Pods κατά τα rolling updates.
- Αξιολόγησε τουλάχιστον την αστοχία ενός Node· για παραγωγή, αξιολόγησε και την αστοχία ζώνης.
- Έλεγξε την πυκνότητα Pods και τον διαθέσιμο χώρο διευθύνσεων IP.
- Έλεγξε cloud quotas για compute, IPs, volumes, load balancers και firewall rules.

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

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

# Πίνακας add-ons

| Add-on | Σκοπός | Υπεύθυνος | Κρισιμότητα | Διαδρομή upgrade | SLO/λειτουργικός στόχος | Metrics/Events | Backup/restore | Επίδραση αστοχίας |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| CNI | δίκτυο Pods και NetworkPolicy | platform | κρίσιμο | staging πριν από production | διαθεσιμότητα δικτύου Pods | σφάλματα CNI, Pods σε Pending | backup της διαμόρφωσης | τα Pods δεν μπορούν να επικοινωνήσουν |
| CSI | δημιουργία storage | platform | κρίσιμο για stateful | έκδοση συμβατή με το cluster | αξιόπιστη δημιουργία PVC | PVC σε Pending, σφάλματα attach | VolumeSnapshots | τα stateful apps εμποδίζονται |
| CoreDNS | service discovery | platform | κρίσιμο | rolling update | χαμηλή καθυστέρηση DNS | ποσοστό NXDOMAIN, καθυστέρηση | backup του ConfigMap | τα Services δεν εντοπίζονται |
| Gateway/Ingress | πρόσβαση HTTP | platform | υψηλή | ελεγχόμενο upgrade του controller | διαθεσιμότητα routing 99,9% | 5xx, υγεία backends | διαμόρφωση από Git | εξωτερικές εφαρμογές μη προσβάσιμες |
| Metrics Server | Resource Metrics API | platform | μέτρια | συμβατή έκδοση με το cluster | διαθέσιμα metrics για HPA | σφάλματα Metrics API | δεν απαιτείται backup δεδομένων | επηρεάζονται HPA και `kubectl top` |
| Observability | metrics/logs/traces | platform | υψηλή | component προς component | διαθεσιμότητα σημάτων | ingest, query, χρόνος διατήρησης | backup storage και διαμόρφωσης | έλλειψη ορατότητας κατά incident |
| GitOps Controller | συγχρονισμός επιθυμητής κατάστασης | platform | υψηλή | δοκιμή σε staging | αξιόπιστο sync | drift, σφάλματα sync | το Git είναι η πηγή | deployments σταματούν ή είναι λανθασμένα |
| Policy Engine | διακυβέρνηση | platform και security | υψηλή | audit πριν από enforce | ασφαλείς πόροι | αναφορές πολιτικών | πολιτικές από Git | μη ασφαλή ή αποκλεισμένα deployments |
| Εργαλείο backup | δυνατότητα restore | platform | υψηλή | δοκιμή restore | επιτυχημένα backup και restore | κατάσταση backup | προστασία των ίδιων των backups | αδύνατο disaster recovery |
| cert-manager | πιστοποιητικά | platform | υψηλή | έλεγχος issuers | έγκυρα πιστοποιητικά | λήξεις, αποτυχίες renewal | προστασία issuers και Secrets | αστοχίες TLS |

# Upgrade Runbook: Kubernetes Minor Upgrade

## 1. Τρέχουσα έκδοση και έκδοση στόχος

- Τρέχουσα έκδοση: v1.x.
- Έκδοση στόχος: v1.y.
- Περιβάλλοντα: πρώτα dev, έπειτα staging και τέλος production.

## 2. Έλεγχος version skew

```bash
kubectl version
kubectl get nodes -o wide
```

## 3. Έλεγχος API deprecations

- Έλεγξε τα manifests στο Git.
- Κάνε render στα Helm charts με `helm template`.
- Κάνε render στα Kustomize overlays με `kubectl kustomize`.
- Τεκμηρίωσε και μετέφερε τα παλαιά API versions.

## 4. Έλεγχος CRDs και Webhooks

```bash
kubectl get crds
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl get apiservices
```

## 5. Συμβατότητα add-ons

Έλεγξε CNI, CSI, CoreDNS, Gateway/Ingress, Metrics Server, observability, GitOps, Policy Engine και εργαλείο backup ως προς τη συμβατότητά τους με την έκδοση στόχο.

## 6. Backup και σημείο restore

- Snapshot του etcd/παρόχου ή backup του cluster.
- Καταγραφή GitOps revision.
- PVC snapshots για stateful workloads.
- Επικύρωση της διαδικασίας restore στο staging.

## 7. Δοκιμή σε staging

Εκτέλεσε ολόκληρο το upgrade στο staging, συμπεριλαμβανομένων smoke tests και προσομοίωσης rollback.

## 8. Upgrade του Control Plane

Managed: χρησιμοποίησε τον μηχανισμό του παρόχου. Self-managed: αναβάθμισε API Server, Controller Manager, Scheduler και etcd σύμφωνα με την τεκμηρίωση λειτουργίας.

## 9. Έλεγχος add-ons

Μετά το upgrade του Control Plane, έλεγξε την κατάσταση των add-ons:

```bash
kubectl get pods -A
kubectl get events -A --sort-by=.metadata.creationTimestamp
```

## 10. Upgrade των Node Pools

```bash
kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# Αναβάθμισε το Node μέσω του παρόχου ή της λειτουργικής διαδικασίας
kubectl uncordon <node>
```

## 11. Smoke tests

- Ο API Server είναι προσβάσιμος.
- Το CoreDNS επιλύει τα Services.
- Το Ingress/Gateway δρομολογεί σωστά.
- Η σύνδεση και αποσύνδεση PVC λειτουργούν.
- Το GitOps συγχρονίζει σωστά.
- Τα SLOs των κρίσιμων εφαρμογών βρίσκονται εντός ορίων.

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

- Αυξήθηκε το ποσοστό σφαλμάτων του API Server ή το API είναι ασταθές.
- Το CNI εμποδίζει τη δικτύωση των Pods.
- Το CoreDNS είναι ασταθές ή παρουσιάζει υψηλό ποσοστό σφαλμάτων DNS.
- Το CSI δεν μπορεί να συνδέσει volumes.
- Ένα Admission Webhook εμποδίζει κανονικά deployments.
- Κρίσιμα workloads δεν γίνονται Ready.
- Τα ευρήματα deprecations δεν έχουν διορθωθεί.
- Το σημείο restore λείπει ή το backup απέτυχε.

## 13. Σχέδιο ανάκαμψης

- Σταμάτησε την αλλαγή.
- Μη συνεχίσεις το upgrade του επηρεαζόμενου Node Pool.
- Επανάφερε προηγούμενη έκδοση add-on, εφόσον είναι συμβατή.
- Επανάφερε workloads σε γνωστό revision μέσω GitOps.
- Σε αστοχία του cluster, ενεργοποίησε την υποστήριξη του παρόχου ή τη διαδικασία restore.

## 14. Τελική αναφορά

- Έκδοση πριν και μετά.
- Χρονικό παράθυρο.
- Επηρεαζόμενα components.
- Αποτελέσματα smoke tests.
- Ανοιχτοί κίνδυνοι.
- Διδάγματα.

# Observability και SLO

## SLO εφαρμογής: checkout-api

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

## SLIs

| SLI | Πηγή |
| --- | --- |
| Ποσοστό επιτυχίας | Ingress/app metrics |
| Καθυστέρηση p95/p99 | App/Ingress metrics |
| Ρυθμός requests | App/Ingress |
| Ποσοστό σφαλμάτων | HTTP 5xx και λειτουργικά σφάλματα |

## Σήματα

| Σήμα | Χρήση |
| --- | --- |
| Metrics | SLO, alerts και χωρητικότητα |
| Logs | ανάλυση βασικής αιτίας |
| Traces | εξαρτήσεις και καθυστέρηση |
| Kubernetes Events | scheduling, image pull, probes και PVC |
| Dashboards | συνολική εικόνα κατάστασης |
| Alerts | ενέργεια με σχετικό runbook |

## Alerts

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

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

| Component | Σήμα |
| --- | --- |
| API Server | καθυστέρηση, 5xx και ρυθμός requests |
| CoreDNS | καθυστέρηση DNS, σφάλματα και replicas |
| Gateway/Ingress | 5xx, υγεία backends και σφάλματα TLS |
| Nodes | Ready, MemoryPressure, DiskPressure και PIDPressure |
| PVC/CSI | PVC σε Pending και σφάλματα attach/detach |
| GitOps | κατάσταση sync, drift και σφάλματα reconciliation |

## Χρόνος διατήρησης και on-call

- Metrics: 30 έως 90 ημέρες ανά περιβάλλον.
- Logs: 14 έως 30 ημέρες· για ρυθμιζόμενα δεδομένα ισχύει η αντίστοιχη πολιτική.
- Traces: μικρότερος χρόνος διατήρησης, με sampling.
- Τα alerts παραπέμπουν σε συγκεκριμένα runbooks και διαδρομές escalation.

# Αξιολόγηση autoscaling: Worker με ουρά

## Αρχική κατάσταση

Workers που βασίζονται σε ουρά επεξεργάζονται εργασίες με αιχμές φορτίου κατά τη διάρκεια της ημέρας και χαμηλό φορτίο τη νύχτα.

## Πόροι

- CPU Request βάσει της χρήσης p95 ανά τύπο εργασίας.
- Memory Request βάσει p95/p99 και περιθωρίου ασφαλείας.
- Προσεκτικός ορισμός memory limit για αποφυγή OOMKills.

## HPA

Το HPA μπορεί να συμπληρώνει την κλιμάκωση βάσει CPU, αλλά δεν είναι ιδανικό για το μήκος ουράς. Το `maxReplicas` περιορίζει το κόστος.

## KEDA

Το KEDA είναι χρήσιμο όταν το μήκος ή η καθυστέρηση της ουράς αποτελεί το καταλληλότερο metric φορτίου. Ενδεικτική στρατηγική:

- `minReplicas`: 1 ή 0, αν είναι αποδεκτός ο χρόνος cold start.
- `maxReplicas`: ανάλογα με τον προϋπολογισμό.
- Κλιμάκωση βάσει μήκους ουράς ανά worker.

## VPA

Χρησιμοποίησε το VPA σε recommendation mode για rightsizing. Χρησιμοποίησε automatic mode μόνο μετά από δοκιμές, επειδή μπορεί να προκαλέσει restart των Pods.

## Node autoscaling

Ο Cluster Autoscaler ή το Karpenter δημιουργεί Nodes για Pods σε κατάσταση Pending. Τα quotas, οι IPs, το NodeClass και οι κίνδυνοι Spot πρέπει να περιορίζονται.

## Κίνδυνοι

| Κίνδυνος | Μέτρο ελέγχου |
| --- | --- |
| ταλαντώσεις | stabilization windows και cooldowns |
| αύξηση κόστους | maxReplicas, προϋπολογισμοί και alerts |
| ελλιπή metrics | fallback και alert |
| ανεπαρκή Requests | παρακολούθηση SLO και OOMKill |
| αργή δημιουργία Nodes | περιθώριο χωρητικότητας, priority και pre-warming |

# Ροή GitOps και CI/CD

## Ροή

1. Commit του κώδικα.
2. Το CI δημιουργεί το image.
3. Το CI εκτελεί tests και scans.
4. Το CI προωθεί το image στο registry.
5. Το CI προσδιορίζει το image digest.
6. Το CI δημιουργεί pull request για αλλαγή manifest.
7. Το review ελέγχει το diff, τις πολιτικές, τους πόρους και την ασφάλεια.
8. Το merge ενημερώνει την επιθυμητή κατάσταση.
9. Ο GitOps Controller συγχρονίζει το cluster.
10. Η ανίχνευση drift αναφέρει χειροκίνητες αποκλίσεις.
11. Το rollback γίνεται μέσω Git revert.

## Identities και δικαιώματα

| Identity | Απαιτούμενα δικαιώματα | Δεν επιτρέπεται |
| --- | --- | --- |
| CI Build Identity | push στο registry, scan και δημιουργία PR | μόνιμα δικαιώματα cluster-admin |
| Reviewer | review και έγκριση στο Git | άμεσες αλλαγές στο cluster χωρίς review |
| GitOps Controller | περιορισμένα δικαιώματα στα Namespaces στόχου | απεριόριστα δικαιώματα cluster χωρίς ορισμένο πεδίο |
| Platform team | add-ons, πολιτικές και πόροι cluster | ad hoc αλλαγές χωρίς review |
| Application team | PRs και αλλαγές εφαρμογών στο δικό της Namespace | δικαιώματα σε ολόκληρο το cluster |

# Πρότυπο tenant: Namespace ομάδας

## Namespace

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-a-prod
  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

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-a-prod
spec:
  hard:
    pods: "30"
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    persistentvolumeclaims: "10"
```

## LimitRange

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

## Role και RoleBinding

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: team-a-prod
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["pods", "pods/log", "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-prod
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

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

## Όριο μεταξύ Professional και Advanced + Security

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

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

## Σκοπός

Ο υποθετικός `database-operator` διαχειρίζεται database instances μέσω Custom Resources.

## CRDs

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

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

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

## Conditions και Events

- `Ready`
- `Progressing`
- `Degraded`
- `BackupReady`
- `RestoreFailed`

## Σημασία για backup

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

## Κίνδυνοι upgrade

- Αλλαγές στο schema των CRDs.
- Conversion Webhooks.
- Finalizers που εμποδίζουν τη διαγραφή.
- Ασύμβατη έκδοση του Operator.
- Παλαιά Custom Resources που δεν μπορούν να μεταφερθούν.

## Κίνδυνοι απεγκατάστασης

- Η διαγραφή CRDs διαγράφει επίσης τα Custom Resources.
- Finalizers μπορεί να παραμείνουν σε εκκρεμότητα.
- PVCs και Secrets μπορεί να μείνουν χωρίς υπεύθυνο.

## Δυνατότητα υποστήριξης tenants

Προτίμησε δικαιώματα περιορισμένα ανά Namespace. Χρησιμοποίησε ClusterRole μόνο όταν απαιτείται τεχνικά.

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

- ClusterRole με `*` χωρίς αιτιολόγηση.
- Απουσία δοκιμής restore.
- Απουσία στρατηγικής versioning των CRDs.
- Απουσία οδηγιών απεγκατάστασης.
- Απουσία υπευθύνων ή SLOs.

# Runbook disaster recovery

## Σενάριο 1: Restore ενός Namespace

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

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

### Σειρά restore

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

### Επικύρωση

- Τα Pods βρίσκονται σε κατάσταση Ready.
- Τα Services έχουν Endpoints.
- Το smoke test της εφαρμογής είναι επιτυχές.
- Τα δεδομένα PVC είναι αναγνώσιμα.

### Παραδοχές RTO/RPO

- RTO: 2 ώρες για ένα τυπικό Namespace.
- RPO: 24 ώρες, ανάλογα με τη συχνότητα των backups.

## Σενάριο 2: Restore ολόκληρου cluster

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

- GitOps repositories.
- Add-ons του cluster.
- Κατάσταση etcd/cluster.
- CRDs και Custom Resources.
- Secrets.
- Δεδομένα PVC.
- Εξωτερικά συστήματα: DNS, registry, identity provider και databases.

### Σειρά restore

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

### Τεκμήρια

- Backup ID.
- Git revision.
- Χρονική στιγμή έναρξης και λήξης του restore.
- Αποτελέσματα smoke tests.
- Αποκλίσεις και επόμενες εργασίες.

# Ανάλυση κόστους

## Πηγές κόστους

| Πηγή | Σημείο μέτρησης | Μέτρο |
| --- | --- | --- |
| υπερβολικά CPU/memory Requests | Requests έναντι πραγματικής χρήσης | rightsizing βάσει p95/p99 |
| ανενεργά workloads | replicas χωρίς κίνηση | πρόγραμμα λειτουργίας dev, αξιολόγηση scale-to-zero |
| PVCs | PVC χωρίς ενεργά Pods | έλεγχος υπευθύνου, snapshot και διαγραφή |
| load balancers | αριθμός εξωτερικών LBs | χρήση κοινόχρηστου Gateway/Ingress |
| egress | χρεώσεις cloud, flow logs | βελτιστοποίηση διαδρομών δεδομένων |
| observability | όγκος logs/metrics | προσαρμογή χρόνου διατήρησης και sampling |

## Κίνδυνοι από ανεπαρκή Requests

Τα πολύ χαμηλά Requests μπορούν να επιδεινώσουν το scheduling, το HPA, τη σταθερότητα και την καθυστέρηση. Rightsizing σημαίνει ρεαλιστικές τιμές, όχι ελάχιστες τιμές.

## Μοντέλο showback

Το κόστος αξιολογείται με βάση τα Labels `owner`, `cost-center`, `environment` και `app` των Namespaces.

## Σχέδιο ενεργειών

| Προτεραιότητα | Μέτρο |
| --- | --- |
| 1 | εισαγωγή υποχρεωτικών Labels και αναφορών κόστους |
| 2 | έλεγχος των Namespaces με τα μεγαλύτερα υπερβολικά Requests |
| 3 | καθαρισμός αχρησιμοποίητων PVCs και load balancers |
| 4 | κλιμάκωση dev workloads σύμφωνα με πρόγραμμα |
| 5 | αξιολόγηση Spot για workers που αντέχουν αστοχίες |

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

## Επισκόπηση πλατφόρμας

- Μοντέλο: Managed Kubernetes.
- Περιβάλλοντα: dev, staging και production.
- GitOps: κεντρικός Controller ανά περιβάλλον.
- Gateway/Ingress: κεντρική διαχείριση.
- Observability: metrics, logs, traces και Events.

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

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

## Γνωστά SLOs

- SLO για API Server και σήματα πλατφόρμας σύμφωνα με το platform SLO.
- SLOs εφαρμογών ανά ομάδα προϊόντος.

## Διαδρομές alerting

- Τα κρίσιμα alerts πλατφόρμας αποστέλλονται στην on-call ομάδα πλατφόρμας.
- Τα alerts εφαρμογών αποστέλλονται στην on-call ομάδα εφαρμογής, με δυνατότητα escalation στην πλατφόρμα.

## Παράθυρα upgrades

- Minor upgrades κάθε τρίμηνο.
- Upgrades add-ons μετά από δοκιμή σε staging.

## Backup και restore

- Το restore Namespace και cluster είναι τεκμηριωμένο.
- Δοκιμή restore τουλάχιστον κάθε τρίμηνο.

## Τα πέντε σημαντικότερα runbooks

1. Αστοχία CoreDNS.
2. Αστοχία CNI/NetworkPolicy.
3. PVC σε κατάσταση Pending λόγω CSI.
4. Αποτυχία GitOps sync.
5. Kubernetes minor upgrade.

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

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

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

- Ορισμένα παλαιά Namespaces δεν έχουν Labels κόστους.
- Η τελευταία δοκιμή restore του cluster έγινε πριν από περισσότερες από 90 ημέρες.
- Δύο add-ons δεν έχουν τεκμηριωμένο SLO.

03-professional-submission/
  answers.md
  platform-blueprint.md
  operating-model.md
  node-pool-sizing.md
  addon-matrix.md
  upgrade-runbook.md
  observability-slo.md
  autoscaling-review.md
  gitops-flow.md
  tenant-standard.md
  operator-review.md
  dr-runbook.md
  cost-review.md
  handover.md