1. Στόχος του Assessment

Αυτό το Assessment ελέγχει αν μπορείτε να σχεδιάζετε, να διαμορφώνετε και να διερευνάτε Kubernetes Workloads που πλησιάζουν περισσότερο σε συνθήκες Production. Εστιάζει στην επιλογή Workload, στα Probes, στον κύκλο ζωής, στη διαχείριση Resources, στο Scheduling, στο NetworkPolicy, στο DNS, στο Ingress ή Gateway API, στο Storage, στο Helm, στο Kustomize και στο συστηματικό Troubleshooting.

Μετά το Assessment πρέπει να είναι σαφές ότι μπορείτε να:

• διακρίνετε Deployment, StatefulSet, DaemonSet, Job και CronJob με βάση τον σκοπό τους,
• ταξινομείτε σωστά Init Containers, Sidecar Containers και Ephemeral Containers,
• διαχωρίζετε τεχνικά τα Startup, Readiness και Liveness Probes,
• εφαρμόζετε Requests, Limits, QoS, LimitRange και ResourceQuota,
• εξηγείτε προβλήματα Scheduling μέσω Events, Node Labels, Taints και Tolerations,
• διαγιγνώσκετε χωριστά Service, DNS, EndpointSlices και NetworkPolicies,
• κατανοείτε το Ingress και το Gateway API ως Resources κανόνων που απαιτούν Controllers,
• χειρίζεστε PVC, PV, StorageClass και StatefulSet σε βασικό επίπεδο,
• αξιολογείτε το Output των Helm και Kustomize πριν το εφαρμόσετε.

2. Προαπαιτούμενα και επιτρεπόμενοι πόροι

Χρειάζεστε:

• Lab Cluster με λειτουργικό CNI,
• CoreDNS,
• kubectl,
• προαιρετικά helm,
• προαιρετικά kubectl kustomize ή kustomize,
• προαιρετικά StorageClass,
• προαιρετικά Ingress Controller ή Gateway Controller.

Επιτρέπονται:

• η επίσημη τεκμηρίωση του Kubernetes,
• οι δικές σας σημειώσεις από το workshop,
• τα kubectl explain, kubectl describe, kubectl logs, kubectl get events,
• τοπικά Manifests που δημιουργήθηκαν κατά το Assessment.

Δεν επιτρέπονται:

• Production Secrets,
• αλλαγές εκτός του Namespace του Assessment, εκτός αν απαιτούνται ρητά,
• Cluster-Wide αλλαγές χωρίς τεκμηρίωση και Rollback.

Προτεινόμενο Namespace:

export NS=exam-intermediate

3. Σενάριο

Μια ομάδα λειτουργεί μια μικρή εφαρμογή Shop στο Lab. Η εφαρμογή αποτελείται από:

• frontend: δέχεται HTTP Requests,
• backend: παρέχει εσωτερικό API στην Port 8080,
• migration: εκτελείται μία φορά πριν από νέα Version,
• cleanup: εκτελείται τακτικά,
• data-demo: αποθηκεύει ένα μικρό αρχείο μόνιμα.

Η εφαρμογή χρειάζεται ελεγχόμενα Health Checks, απαιτήσεις Resources, όρια Namespace, NetworkPolicies και σαφή διάγνωση. Η εξωτερική δημοσίευση γίνεται μέσω Ingress ή Gateway API, αν υπάρχει Controller. Αν δεν υπάρχει Controller, αυτό πρέπει να τεκμηριωθεί σωστά.

4. Αναμενόμενη υποβολή

Υποβάλετε έναν φάκελο ή Archive με τα ακόλουθα αρχεία:

02-intermediate-submission/
  answers.md
  architecture-decision.md
  workloads/
    frontend.yml
    backend.yml
    migration-job.yml
    cleanup-cronjob.yml
  resources/
    limitrange.yml
    resourcequota.yml
  networking/
    services.yml
    networkpolicies.yml
    ingress-or-gateway.yml
  storage/
    statefulset.yml
  packaging/
    kustomize-output.md
    helm-output.md
  troubleshooting.md
  evidence.md
  cleanup.md

Αν δεν διατίθενται Helm, Gateway API, Ingress Controller ή StorageClass, τεκμηριώστε τον περιορισμό και δώστε ένα τεχνικά σωστό παράδειγμα Manifest ή μια εναλλακτική αξιολόγηση που μπορεί να επαληθευτεί.

5. Μέρος A: Ερωτήσεις γνώσεων

Απαντήστε με ακρίβεια και με λειτουργικό πλαίσιο.

1. Πότε χρησιμοποιείτε Deployment, StatefulSet, Job και CronJob;
2. Ποια είναι η διαφορά μεταξύ Init Containers, Sidecar Containers και Ephemeral Containers;
3. Ποιος είναι ο ρόλος των Startup Probe, Readiness Probe και Liveness Probe;
4. Γιατί ένα υπερβολικά επιθετικό Liveness Probe μπορεί να προκαλέσει βλάβη;
5. Πώς επηρεάζουν τα CPU/Memory Requests το Scheduling και το HPA;
6. Ποια είναι η διαφορά μεταξύ των QoS Classes Guaranteed, Burstable και BestEffort;
7. Ποιος είναι ο ρόλος των LimitRange και ResourceQuota;
8. Ποια είναι η διαφορά μεταξύ nodeSelector, Affinity, Taints και Tolerations;
9. Γιατί ένα Pod μπορεί να παραμείνει σε κατάσταση Pending ακόμη και με σωστό Manifest;
10. Πώς αλληλεπιδρούν Service, EndpointSlice, Pod Readiness και DNS;
11. Γιατί πρέπει να λαμβάνεται ρητά υπόψη το DNS Egress σε NetworkPolicies με Default Deny;
12. Ποια είναι η διαφορά μεταξύ Ingress Resource και Ingress Controller;
13. Ποιους ρόλους έχουν τα PV, PVC, StorageClass και CSI;
14. Γιατί το hostPath σε ένα Lab δεν αποτελεί αυτομάτως λύση για Production;
15. Τι ελέγχετε για PVC Pending, Service χωρίς Endpoints και CreateContainerConfigError;

6. Μέρος B: Απόφαση για Workloads και αρχιτεκτονική

Δημιουργήστε το architecture-decision.md. Για κάθε απαίτηση, περιγράψτε το κατάλληλο Kubernetes Resource και αιτιολογήστε την απόφαση.

7. Μέρος C: Πρακτικές εργασίες

Εργασία C1: Namespace, ResourceQuota και LimitRange

1. Δημιουργήστε το Namespace exam-intermediate.
2. Δημιουργήστε LimitRange με προεπιλεγμένα Requests και Limits.
3. Δημιουργήστε ResourceQuota για Pods, CPU και Memory.
4. Δείξτε ότι ο API Server απορρίπτει ένα Pod που υπερβαίνει τα όρια.

Ελάχιστες απαιτήσεις Quota:

pods: 10
requests.cpu: 2
requests.memory: 2Gi
limits.cpu: 4
limits.memory: 4Gi

Εργασία C2: Frontend και Backend με Probes

Δημιουργήστε δύο Deployments:

• frontend με Image curlimages/curl:8.8.0 ή συγκρίσιμο ασφαλές Test Image,
• backend με HTTP Test Server στην Port 8080, για παράδειγμα registry.k8s.io/e2e-test-images/agnhost:2.53 με netexec.

Απαιτήσεις:

• ουσιαστικά CPU/Memory Requests και Limits,
• Readiness Probe για την κυκλοφορία του Service,
• Liveness Probe για περιπτώσεις που απαιτούν πραγματική επανεκκίνηση,
• Startup Probe αν η εφαρμογή εκκινεί αργά,
• σαφή Labels: app, component, environment,
• Services για Frontend και Backend.

Τεκμηριώστε γιατί το Readiness δεν εξυπηρετεί τον ίδιο σκοπό με το Liveness.

Εργασία C3: Job και CronJob

Δημιουργήστε:

• Job migration που ολοκληρώνεται επιτυχώς μία φορά,
• CronJob cleanup που εκτελείται κάθε ώρα,
• concurrencyPolicy: Forbid για το CronJob,
• ουσιαστικές τιμές successfulJobsHistoryLimit και failedJobsHistoryLimit.

Τεκμηριώστε γιατί ένα Deployment θα ήταν τεχνικά λιγότερο κατάλληλο για αυτόν τον σκοπό.

Εργασία C4: Έλεγχος Scheduling

1. Προσθέστε το Label exam-role=apps σε ένα Lab Node.
2. Δημιουργήστε Pod ή Deployment με αντίστοιχο nodeSelector.
3. Δημιουργήστε δεύτερο Pod με nodeSelector που δεν ταιριάζει.
4. Τεκμηριώστε τα Events για την κατάσταση Pending.
5. Προσθέστε Taint στο Node με το Label.
6. Δείξτε τη διαφορά μεταξύ Pod χωρίς Toleration και Pod με αντίστοιχο Toleration.
7. Αναιρέστε καθαρά τις αλλαγές στο Node.

Εργασία C5: Default Deny NetworkPolicy με στοχευμένες εξαιρέσεις

Δημιουργήστε NetworkPolicies με τις ακόλουθες απαιτήσεις:

1. Default Deny για Ingress και Egress στο Namespace.
2. Επιτρέψτε DNS Egress προς το CoreDNS.
3. Το frontend επιτρέπεται να συνδέεται στο backend στην TCP Port 8080.
4. Το υπόλοιπο Egress παραμένει αποκλεισμένο.
5. Τεκμηριώστε αν το CNI σας επιβάλλει πράγματι NetworkPolicies.

Evidence:

kubectl get networkpolicy -n exam-intermediate
kubectl exec <frontend-pod> -n exam-intermediate -- nslookup backend
kubectl exec <frontend-pod> -n exam-intermediate -- curl -s --max-time 5 http://backend:8080/hostname

Εργασία C6: Ingress ή Gateway API

Ελέγξτε πρώτα αν υπάρχει Controller:

kubectl get ingressclass
kubectl get gatewayclass 2>/dev/null || true

Αν υπάρχει Ingress Controller:

• δημιουργήστε Ingress Resource με Hostname shop.localtest.me,
• δρομολογήστε την κίνηση στο σωστό Service,
• τεκμηριώστε Controller Events και αντιστοίχιση Backend.

Αν υπάρχει Gateway API:

• δημιουργήστε ή περιγράψτε ένα μοντέλο Gateway/HTTPRoute,
• τεκμηριώστε ParentRef, Hostname και BackendRef.

Αν δεν υπάρχει Controller:

• δημιουργήστε ένα παράδειγμα Manifest,
• εξηγήστε γιατί το Resource δεν δρομολογεί πρακτικά την κίνηση χωρίς Controller.

Εργασία C7: PVC και StatefulSet

1. Ελέγξτε τα διαθέσιμα StorageClasses.
2. Δημιουργήστε StatefulSet data-demo με volumeClaimTemplates.
3. Γράψτε ένα αρχείο στη διαδρομή /data/test.txt.
4. Διαγράψτε το Pod.
5. Μετά την αναδημιουργία του, επαληθεύστε ότι το αρχείο εξακολουθεί να υπάρχει.
6. Τεκμηριώστε το StorageClass και τους περιορισμούς του Lab.

Εργασία C8: Render με Helm και Kustomize

1. Δημιουργήστε ένα μικρό Kustomize Base και ένα dev Overlay.
2. Κάντε Render του Overlay με kubectl kustomize.
3. Δημιουργήστε ελάχιστο Helm Chart ή χρησιμοποιήστε ένα τοπικό παράδειγμα Chart.
4. Κάντε Render του Chart με helm template.
5. Συγκρίνετε πόσο εύκολα ελέγχονται οι αλλαγές, την Παραμετροποίηση και τον κίνδυνο σφαλμάτων.

8. Μέρος D: Διαδρομή Troubleshooting

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

9. Βαθμολόγηση

10. Κριτήρια άμεσης αποτυχίας

Το Assessment θεωρείται αποτυχημένο ανεξάρτητα από τη βαθμολογία, αν:

• χρησιμοποιηθούν Production Resources ή Secrets,
• αφεθούν Cluster-Wide αλλαγές χωρίς τεκμηρίωση,
• δεν αναιρεθούν τα Node Taints ή Labels,
• η υποβολή δεν περιέχει Evidence για τα πρακτικά βήματα,
• ο εξεταζόμενος δεν μπορεί να εξηγήσει τη διαφορά μεταξύ Readiness και Liveness,
• ο εξεταζόμενος δεν μπορεί να διαγνώσει Service χωρίς Endpoints.

11. Λίστα ελέγχου εξεταστή

• Τα Namespace, LimitRange και ResourceQuota υπάρχουν και έχουν τεκμηριωθεί.
• Τα Frontend και Backend έχουν ουσιαστικά Probes και Resources.
• Χρησιμοποιούνται Job και CronJob για εργασίες πεπερασμένης διάρκειας και προγραμματισμένες εργασίες.
• Οι δοκιμές Scheduling περιλαμβάνουν Node Label, λανθασμένο Selector, Taint και Toleration.
• Τα NetworkPolicies περιλαμβάνουν Default Deny, εξαίρεση DNS και επιτρεπόμενη επικοινωνία της εφαρμογής.
• Η εξάρτηση του Ingress/Gateway από Controller έχει ταξινομηθεί σωστά.
• Η διατήρηση δεδομένων με StatefulSet/PVC έχει επαληθευτεί ή έχει εξηγηθεί ο περιορισμός.
• Το Output των Helm/Kustomize έχει γίνει Render πριν από το Apply.
• Η τεκμηρίωση Troubleshooting περιέχει σύμπτωμα, διάγνωση, αιτία, διόρθωση και επαλήθευση.